301–310 of 520 posts
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/
Earlier quoted context omitted.
Already counting down the days before yarn is considered old and broken and people are recommending switching to the next hot package manager/bundler...
It badfles me that technologists commonly complain about new technology. As far as I can tell your complaint boils down to “people should stop making and switching to new things”.. I find it hard to understand why someone with this attitude would be a technologist of any kind, and I find the attitude really obnoxious.
I don't get why not just use git repo registry (e.g. github) for package management. If you work in a "strict" environment you can basically fork all your dependencies and use your own git repo registry. NPM already allows using git repos, but needs some tweaks to allow better support: * allow versioning via git tags * store git commit in `package-lock.json`. * maybe something else...
What would you gain by storing the commit in the lock file? You can reference commits in package.json already.
Ideally if all packages would use commits, and the installation algorithm will never change, then there will be no need for lock files.
In reality some packages will use NPM existing mechanism, so "git-based algorithm" will need to accommodate for that by reading git repo of the NPM package and referring to a specific commit, which should be store in `package-lock.json`.
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.
Stop pointing your package managers to the public registry. Unfortunately with NPM this is still awkward, because as soon as you try to shrinkwrap your project, it doesn't just pin the version numbers, it also pins the full source location. That's in direct conflict with (and apparently takes precedence over) using one of the local caching proxies that would otherwise be a useful practical solution to this problem, a…
NPM has its own lockfiles now, similar to yarn.
> It has a few problems of its own, notably surprising, quiet updates to the lock file when using the default options
This I've never noticed. I'm genuinely curious how it would happen. The only way I imagine it might happen is if you do a fresh install with no cache and some of the packages have moved or changed on the registry. Do you happen to have more details?
Vendor your dependencies that are needed to run build your applications. Period.
Earlier quoted context omitted.
Already counting down the days before yarn is considered old and broken and people are recommending switching to the next hot package manager/bundler...
It badfles me that technologists commonly complain about new technology. As far as I can tell your complaint boils down to “people should stop making and switching to new things”.. I find it hard to understand why someone with this attitude would be a technologist of any kind, and I find the attitude really obnoxious.
This is particularly true for package/dependency management, but the attitude is found more broadly.
For what it's worth, the javascript world isn't alone here. Python, with its new Pipfile/pipenv system is on its, what, fifth, sixth? stab at solving package management "once and for all" and it's all truly dire and not something I depend on when I have the choice.
Nix solves pretty much all of these problems and a few more, but I expect it to be a decade or so before people realize it.
I'm not complaining about new things. These aren't new things. They're about a decade behind the curve.
Could someone please add NPM to the title?
Earlier quoted context omitted.
maybe it's time to push for adding signed packages to npm long discussion here: https://github.com/node-forward/discussions/issues/29
Signing won't help unless the end user specifies the signature or certificate that they expect (signing would only help ensure package upgrades are from the same author). If you're going to have clients specify a signature anyway, then you don't need to sign packages, you just need strong one way hash function, like SHA-1024 or something. User executes "pkg-mgr install [package name] ae36f862..." Either way, every tu…
Granted it wouldn't save those adding a new package to a project the first time, but it would save the bacon of anyone re-running "npm install" in an existing project, for example during a deploy, or when trying to upgrade to a newer version of a given package.