Idea: support package-lock.json from npm 5

[kof]

I think we will face the issue in the near future that we get 2 lock files in one project, especially because npm creates it by default. Is there any chance that yarn could use the package-lock.json from npm by default if it is detected?

It would be especially useful for libraries when maintainer uses package-lock, others can still use yarn when installing it.

[paulirish]

I expect this will change in the future, but... What is the current best practice for handling both package-lock.json and yarn.lock?

These are the options I'm seeing...

1. Don't, and only support one of these in your project.
2. Everyone manually keeps them in sync for every dependency change
3. Use some tool to rebuild one of the locks when you change the other. (I'm hoping for this one :)
4. Just eat the pain and wait?

[joggienl]

I would opt for option 1 or 4.. keeping multiple files for the same in sync is tedious and error prone.
On the other side, a downside of choosing to support one of both is that you somewhat force your users to use either yarn or npm, but I think that this would be less harmful than different packages for different package managers.

So our projects use either a package-lock.json or an yarn.lock file, the first option.

[karfau]

At work, we are currently in the following weird situation:

• using yarn for 95% of our CI, but one step is using npm, because it is the only way we could make it work inside docker.
• as we knew no way of syncing the files we decided to .gitignore package-lock.json for now, because our minimal version of npm is LTS, which doesn't support ti anyway.
• we will soon (days or weeks) upgrade to use node v8 and npm v5 as minimal version, then we might switch to only use/support package-lock.json and .gitignore yarn.lock, in case there is no option to sync them.

The following approaches would work for us:
A) yarn using the values from package-lock.json for installing
B) yarn using the values from package-lock.json to create/update yarn.lock
C) an extra tool to create+sync yarn.lock from package-lock.json

In the general packager case Yarn could potentially be used for Packagist (there's a prototype floating around), and perhaps even CocoaPods, in addition to NPM. A PHP project, for example, might have a composer.lock and a package.json for managing NPM scripts. Might leaning too far into NPM locking behaviors limit some of these future possibilities for packager extensibility?

[nottrobin]

If yarn starts managing other types of dependencies, it is still always expected to generate the exact same dependency versions as any other managers of the same dependencies. (yarn install or npm install will give you identical dependencies).

So I would have thought it should always follow the prevailing standard for the type of dependency. I.e., for PHP dependencies it should use composer.lock, for NPM it should use package-lock.json.

The way I see it Composer is to Pear as Yarn is to NPM. Difference being NPM uses NPM where Composer uses Packagist. If Yarn were to maintain its own standards we could prevent gridlock and tooling complexity which could hamstring Yarn and inhibit forward momentum in other packagers.

Is it naïve to think 80% case could boil down to one packager, with additional packagers to add value for 20% and ancillary use cases? It seems such an approach might serve the majority while limiting complexity, allowing innovation on the fringes which could then be generalized and pulled into Yarn as the value proposition becomes clear longer-term.

It has always seemed to me this is what NPM itself is doing right now. I could be wrong.

[nottrobin]

Yes I agree, Yarn wants to maintain its independent space as far as possible, so it has the flexibility to provide a better experience. Which is why, for example, Yarn's CLI is deliberately not compatible with NPM's.

However, I think lock files are outside of the space where Yarn can reasonably maintain independence. package-lock.json and composer.lock are committed to the repository, alongside package.json and composer.json. These are not tool-specific files, they are instead project-specific files specifying the exact dependency versions that the project is guaranteed to work with.

When NPM wasn't offering the ability to lock dependencies, it made sense for Yarn to create its own yarn.lock. But now that NPM has defined a standard way for projects to specify the explicit dependency versions that they are known to work with, and furthermore it is named similarly to the package.json that Yarn already relies on, it doesn't make sense for Yarn to continue to go its own way.

For Yarn to be a useful tool, it has to allow developers to follow standard models in their projects, so the project can remain tool-agnostic. Which, after all, is why Yarn was built on top of package.json and not its own separate dependency file.