feat(core): add package manager parsers and stringifiers

[meeroslav]

This PR adds parseLockFile and writeLockFile functions to nx necessary for future pruning functionality and dependency tracking during tasks.

Current Behavior

Expected Behavior

Related Issue(s)

Related to #9761

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 0582080. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 12 targets

• nx affected --target=e2e --base=dd6f38e692899de73809d26c928714203789c811 --head=058208055587444c7fb14fe4874505fece375995 --exclude=e2e-storybook,e2e-storybook-angular,e2e-react-native,e2e-detox,e2e-make-angular-cli-faster --parallel=1
• nx affected --target=test --base=dd6f38e692899de73809d26c928714203789c811 --head=058208055587444c7fb14fe4874505fece375995 --parallel=1
• nx affected --target=build --base=dd6f38e692899de73809d26c928714203789c811 --head=058208055587444c7fb14fe4874505fece375995 --parallel=3
• nx-cloud record -- yarn depcheck
• nx affected --target=lint --base=dd6f38e692899de73809d26c928714203789c811 --head=058208055587444c7fb14fe4874505fece375995 --parallel=3
• nx-cloud record -- yarn nx workspace-lint
• nx-cloud record -- yarn check-lock-files
• nx-cloud record -- yarn check-commit
• nx-cloud record -- yarn nx format:check --base=dd6f38e692899de73809d26c928714203789c811 --head=058208055587444c7fb14fe4874505fece375995
• nx-cloud record -- yarn check-imports
• nx-cloud record -- yarn documentation
• nx build typedoc-theme

---

Sent with 💌 from NxCloud.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
nx-dev	✅ Ready (Inspect)	Visit Preview	Sep 20, 2022 at 6:25PM (UTC)

[meeroslav]

We disable this explicitly, because of pnpm's package name hacks.

[vsavkin]

I think the pair of parseLockFIle/writeLockFile is a good interface.

Some notes and questions:

1. Should parseLockFIle be generic?
   LockFileData is generic, but that type parameter is not used in the parseLockFile/writeLockFile functions, and I don't think we would use it.

After all, we want to write lock-file-oriented code in a polymorphic way. E.g., if we want to prune the lock file, we would want to write that code without any specific yarn, npm etc stuff. If it is possible, the parse/write functions cannot be generic. If it is not possible, then I don't think hose functions are needed because the if statement you have inside will have to outside. Does it make sense?

We use generics in the same way when creating a project graph. The generic parameter there is not used.

2. Should parseLockFIle take parameters?

I don't think it should cause I imagine all the unit testing will be done around package-specific functions (you will test npm,yarn,pnpm versions directly).

3. I don't think the tests should be in the lockfile-test folder. All unit tests should be based on parsing and serializing strings. We need at least some unit tests for each package manager.

[vsavkin]

Left some comments.

[meeroslav]

Thank you for checking the PR.

I'll check if we can get rid of generics without making code too messy. But generally, all callers of parse, stringify (and future prune) should be agnostic of package manager (and lock file generic type).

Regarding the lock files in script folder, all of that will be gone. It was more convenient while debugging, but I'll drop that entire folder and add tests with fixtures. This would also make the working directory param obsolete.

Once I add tests, the PR will be ready for full review.

[Nikamura]

Hey guys, why was @zkochan/js-yaml added as dependency instead of using js-yaml ?

https://www.npmjs.com/package/@zkochan/js-yaml/v/0.0.6
https://www.npmjs.com/package/js-yaml

[meeroslav]

@Nikamura Because of the lock file pruning. The @zkochan/js-yaml adds additional functionality on top of js-yaml, which unfortunately is necessary to properly construct pnpm-lock.yaml.

[github-actions]

This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request.