Yarn support?

[nedrichards]

Like all great things in the JS ecosystem, there are two competing package management standards. Yarn has it's own yarn.lock file that describes roughly the same set of info as the package-lock.json. There is controversy here over how to hold these two concepts in tension. Do you think we should add yarn support to a tool like this? Or make a separate flatpak-yarn-generator script?

[alexlarsson]

The question is, does the yarn tooling let us pre-seed the caches in a similar way so that we can use it?

[nedrichards]

Yep, that's the point of the yarn.lock file. Documentation here. An idle github search brings up a whole host of people using it for things like that, including this rather natty yarn2nix converter.

Having a quick look at two real world examples of yarn and npm files, they look somewhat similar!

[alexlarsson]

Yeah, it seems like npm5 added lock file very much influenced by how yarn works.

[alexlarsson]

The question is, give an yarn lockfile with:

package-1@^1.0.0:
  version "1.0.3"
  resolved "https://registry.npmjs.org/package-1/-/package-1-1.0.3.tgz#a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0"

We can generate a source with this uri and checksum. However, where do we put the pre-downloaded one so that yarn install uses that instead of downloading it from the network.

[alexlarsson]

As for wheer to put the yarn support. I think maybe we should add a single flatpak git repo with the tools for all of these things, including the pypi one elad is doing.

[nedrichards]

The single repo for flatpak-tools (or similar) makes sense.

In the example above I think you're supposed to use the yarn 'offline mirror' concept, which may be a bit of a faff. (it may be that the config in the post is out of date, sources are unclear)

[alexlarsson]

Yeah, that looks similar to the cache npm5 uses, should be easy to do the same thing then.

[nedrichards]

Code moved to a separate repo https://github.com/flatpak/flatpak-builder-tools