81–90 of 520 posts
Hmm, I Java world we pretty much always used a local (company-owned) Maven proxy server, which grabbed packages from public repos and cached them locally to make sure builds still work if public servers were down or slow... or packages disappeared. This isn't a standard practice in JS world?
Hmm, I Java world we pretty much always used a local (company-owned) Maven proxy server, which grabbed packages from public repos and cached them locally to make sure builds still work if public servers were down or slow... or packages disappeared. This isn't a standard practice in JS world?
It might not be as standard a practice in the Java world as you think.
Hmm, I Java world we pretty much always used a local (company-owned) Maven proxy server, which grabbed packages from public repos and cached them locally to make sure builds still work if public servers were down or slow... or packages disappeared. This isn't a standard practice in JS world?
Btw. for those who don't know: Yarn (which is an alternative to npm) uses a global cache [1] on your machine which speeds things up, but probably also protects you from immediate problems in cases like the one currently on progress (because you would probably have a local copy of e.g. require-from-string available). [1] https://yarnpkg.com/lang/en/docs/cli/cache/
Already counting down the days before yarn is considered old and broken and people are recommending switching to the next hot package manager/bundler...
2018 looks interesting, everything seems suddenly broken.
In my org, we use Artifactory as a cache between us and external sources. They have a free version too. I'd encourage everyone to use it, or something like it. Stop pointing your package managers to the public registry.
Btw. for those who don't know: Yarn (which is an alternative to npm) uses a global cache [1] on your machine which speeds things up, but probably also protects you from immediate problems in cases like the one currently on progress (because you would probably have a local copy of e.g. require-from-string available). [1] https://yarnpkg.com/lang/en/docs/cli/cache/
I never understood the love for package managers that directly hook and import things into your codebase or repo or even worse servers. I guess the benefit is that "it just works", but the fact that you do not know where a package is coming from can't be worrying just me. In my company we take the stable version of the library we want to use and we self-host it. We basically have added a cache that we manage and cont…
"Harvesting credit card numbers and passwords from websites"
https://news.ycombinator.com/item?id=16084575
If you self-host a stable version, you'll have some time to hear about potential problems in a new version before updating it.
Yikes, what is it about node/npm/javascript that makes it feel like a house of cards?
Earlier quoted context omitted.
> Gah. Moments like these always gives me a bit of panic, since I realize that so much of my software relies on external sources. Install an instance of Sonatype Nexus, create a proxy-repo for npm (and Maven if you also use Java) and that's it. What, however, won't be caught is Docker (because that crap insists on directly talking to the Dockerhub servers, which is a giant security hole waiting to happen) and PHP com…
Or just don't .gitignore node_modules, then diff any changes to node_modules on update.