I maintain a starter kit that bundles a Yarn yarn.lock file.
Now that NPM v5 is released and recommends committing its own package-lock.json, I'd like to include both.
Is it possible to generate both files without actually installing anything, solely for the purpose of committing the locks?
Note: The reason for including both is that, as a starter kit, the end-user may choose to use Yarn or NPM. I have no control over their environment, so I'd like to support both out-the-box.
Related
As title indicates, I'm working on a project where different members have used different tools (NPM and Yarn) for handling packages and modules etc.
We aim to transition to use ONLY Yarn (not our decision). Would anyone be able to share resources detailing how to accomplish such a thing? Or help quickly walk me through the steps?
I tried googling for answers but every single result is yet another article explaining why you should ditch NPM/Yarn and move your project to Yarn/NPM, without explaining the steps one would need to take to move from using both to just one mid-project. Thanks!
It looks like Yarn has a page talking about how to migrate to it from NPM:
https://yarnpkg.com/lang/en/docs/migrating-from-npm/
In most cases, running yarn or yarn add for the first time will just work. In some cases, the information in a package.json file is not explicit enough to eliminate dependencies, and the deterministic way that Yarn chooses dependencies will run into dependency conflicts. This is especially likely to happen in larger projects where sometimes npm install does not work and developers are frequently removing node_modules and rebuilding from scratch. If this happens, try using npm to make the versions of dependencies more explicit, before converting to Yarn.
As of Yarn 1.7.0, you can import your package-lock.json state, generated by npm to Yarn, by using yarn import.
They use many of the same files and structures. The important thing is to check-in the yarn.lock file and make sure everyone is installing using Yarn instead of NPM.
If you have a build server, you could probably use it to enforce those dependencies, but it would be more work.
we are developing an large web application which depend some private npm packages and public packages. we need to lock the version, but we can not sure which time to update these package and update the lock file.
In my web project, I update lock files only if i add, update, remove a node package for my project. In this case, I take advantage to update all packages of my lock files.
For the other developers who work in my web project, they use cmd :
npm ci
or
yarn install --frozen-lockfile
They must not absolutely modify the lock files.
Furthermore, i am sure that everybody have the same environment (for behavioral reproduction).
While using npm I've not once encountered a problem when some package somewhere deep in the dependency tree receives minor or even patch update, but actually introduces a breaking change. Finding the culprit package is not always easy. And the problem most of the time hits CI the hardest as it often performs clean npm install. So all that remains is waiting a day or two till package authors notice and fix the error.
Using exact versions in package.json doesn't help either as referenced packages have dependencies of their own and they are not always specified with exact versions.
Such breaking changes are a fact of life I suppose, as no one is immune to mistakes, and shear number of packages directly and indirectly used in any bigger than trivial project is huge.
So, how to prevent such inevitable breaking changes from disrupting development process?
The only thing I've been able to imagine is a hypothetical feature of npm that would only allow installing packages no younger than now().addDays(-2).
A package-lock.json (npm5) or a npm-shrinkwrap.json (npm 2-4) if created and committed to source control will lock in all of your dependencies and their dependencies so that the exact same versions will be installed. package-lock.json is now generated automatically, and npm-shrinkwrap.json can be created with npm shrinkwrap command. Once these files are created, they will be automatically updated on subsequent npm install --save ... commands.
In my NodeJS projects I use of course some external modules, those modules relies on other packages. Some of the developer maintaining those modules are very slow at updating the modules they use in their own project. Even when the issue is regarding security.
Is it possible to bump up a NPM modules within a modules?
You can change the package.json file within those npm packages you wish to update the dependencies for, but really this isn't an ideal solution. Any time an npm install is performed you'll lose those changes. Best to, if possible, fork the Git repos for those packages and make the changes yourself.
Can someone explain to me the difference between NPM, Bower and Composer.
They are all package managers - correct?
But when should each one be used?
Also, each one appears to have a json file that accompanies it, does this store all the packages you require so they can be installed by cmd line? Why do you need this file?
[update, four years later]
bower is deprecated, and should not be used anymore for new projects. To a large extent, it has been subsumed into node dependency management (from their website: "While Bower is maintained, we recommend using Yarn and Webpack or Parcel for front-end projects").
yarn came out of the wood as a better npm (fixing several of npm flaws), and this is really what you should use now, as it is the new de-facto standard if you are doing front-end or node development. It does consume the same package.json as npm, and is almost entirely compatible with it.
I wouldn't use composer at this point (because I wouldn't use php), although it seems to still be alive and popular
[original answer]
npm is nodejs package manager. It therefore targets nodejs environments, which usually means server-side nodejs projects or command-line projects (bower itself is a npm package). If you are going to do anything with nodejs, then you are going to use npm.
bower is a package manager that aims at (front-end) web projects. You need npm and nodejs to install bower and to execute it, though bower packages are not meant specifically for nodejs, but rather for the "browser" environment.
composer is a dependency manager that targets php projects. If you are doing something with symfony (or plain old php), this is likely the way to go
Summing it up:
doing node? you do npm
doing php? try composer
front-end javascript? try bower
And yes, the "json" files describe basic package information and dependencies. And yes, they are needed.
Now, what about the READMEs? :-)
https://github.com/bower/bower
https://www.npmjs.org/doc/cli/npm.html
https://getcomposer.org/doc/00-intro.md