Trouble Using Yarn Lockfile (nodejs-package-lock-v3)

[ebarruel]

I am using a yarn lockfile and keep getting this error: error: [json.exception.parse_error.101] parse error at line 1, column 1: syntax error while parsing value - invalid literal; last read: '#'

The comment is just the header stating that it's an auto-generated file and on the next line that it's a v1 yarn lockfile. I'm not sure if I'm supposed to somehow tell d2n that I'm using yarn.lock besides including this in my default.nix:

nodejs-package-lock-v3 = {
    packageLockFile = "${config.mkDerivation.src}/yarn.lock";
};

Is there another option I'm not properly setting?

[DavHau]

Yarn lock files are currently not supported. You have to use npm to create a paclage-lock.json file

[tobiasBora]

Hum, out of curiosity, why do this thread claims it is supported? Is it refering to another format, or to a legacy version of dream2nix? https://discourse.nixos.org/t/yarn-plugnplay-and-direnv-packaging/19759/12?u=tobiasbora

Second on dream2nix. I’ve used it extensively to package extremely complex yarn-based monorepos with workspaces and a variety of other off use cases, with close to 100% success rate with nodejs-based packages. The nodejs ecosystem is pretty much solved for dream2nix. It has support for both pure (package-lock.json, yarn.lock) and impure translations and provides many paths to solve various problems, such as package overrides, dependency injections, building without devDependencies (so build from the outside with nix instead), etc.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixify-yarn-v3-with-flake/38848/2

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixify-yarn-v3-with-flake/38848/3

[DavHau]

Yes, yarn was supported in a previous version of dream2nix but deprecated to reduce maintainership burden. Any reason why you cannot use npm for your use case?

[PetarKirov]

@DavHau At work we have several projects all using Yarn v3 and v4. Some of the reasons behind the choice of yarn (vs npm) were:

• Support for workspaces - all of our projects have a mono-repo like structure and were using Yarn for this feature (which of course includes hoisting dependencies to the root of the project across all packages in the repo) years before npm gained support for it
• Yarn PnP - node_modules should be killed with fire!
• Plugins
  • Using yarn-plugin-nixify yarn/yarn install pre-fetches all dependencies into the Nix Store and re-generates the yarn-project.nix file listing all dependencies. This ensures that developers working on the project won't forget to update the Nix file with the yarn.lock file is updated. Also makes the builds faster as yarn-plugin-nixify prefetches much faster than nix build fetches (with no prior prefetch).
  • @yarnpkg/plugin-version - yarn v4 bundles this plugin, but previously if you wanted to use the Yarn release workflow one had to install it manually, which we did
  • @yarnpkg/plugin-workspace-tools - see https://v3.yarnpkg.com/cli/workspaces/focus and https://v3.yarnpkg.com/cli/workspaces/foreach
• Performance - while npm has gotten many performance improvements over the last years, it used to be the case that our projects would install up to 10x faster with Yarn v2/v3 compared to NPM, which made migrating Yarn an obvious choicde
• Built-in portable shell for package.json scripts. Before, when we were using npm we used to have many portability issues with scripts (especially with developers working on Windows! :@). Nowadays with Yarn v3+ we haven't had any such issues that I can think of.
• Protocols - especially the workspace, link and git ones.

[vtgen]

same here fwiw. we are pretty heavily ingrained into yarn; with yarn specific tooling already stable and entrenched.

i think we can generate a package.lock.json temporarily; but after a couple hours of putzing with it i am giving up.