Remove `package-lock.json`

[remcohaszing]

Initial checklist

• [x] I read the support docs
• [x] I read the contributing guide
• [x] I agree to follow the code of conduct
• [x] I searched issues and couldn’t find anything (or linked relevant results below)
• [x] If applicable, I’ve added docs and tests

Description of changes

Lockfile version 3 is the successor of version 1. Version 2 is an intermediate format which includes data for both lockfile versions 1 and 3. This means it’s about twice as big and contains twice as many diffs to review.

Most unified packages don’t use lockfiles, but I do think it’s a good idea to use for VSCode plugins. For example new features introduced in unified-language-server shouldn’t go unnoticed for VSCode Remark users.

[wooorm]

For example new features introduced in unified-language-server shouldn’t go unnoticed for VSCode Remark users.

Can you expand on this? I don‘t quite get it. Shouldn’t we then use a ~ version range for unified-language-server, and release a new version of this package when that package updates?

[wooorm]

@remcohaszing ping!

[codecov-commenter]

Codecov Report

Merging #83 (7531bf1) into main (c9e9ae3) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #83   +/-   ##
=======================================
  Coverage   50.00%   50.00%           
=======================================
  Files           1        1           
  Lines          22       22           
  Branches        3        3           
=======================================
  Hits           11       11           
  Misses          9        9           
  Partials        2        2           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update c9e9ae3...7531bf1. Read the comment docs.

[remcohaszing]

I have mixed feelings about lockfiles. I like having reproducible builds, but managing lockfiles can be a churn. I have been using lockfiles for my own projects, but have also been thinking of removing them.

I can relate with this comment

Lockfiles for apps, but not for packages.

In case of a VS Code extension, I lean towards saying it’s more of an app than a package. The end user won’t get updates by updating their dependencies or force reinstalling it. They rely on the release cycle of this plugin. If unified-language-server gets a release with new features, remark-language-server gets these features automatically. For vscode-remark another release is needed and it makes sense to document the new features in the release notes, even if they come from upstream.

Regardless of the stance on lockfiles, I do believe package-lock.json v3 is superior over v2 (the npm default), because v2 is just lockfile v1 and v3 combined in one JSON file, duplicating its size.

[wooorm]

I’m in favor of removing it instead of updating. If we didn’t remove, then updating would be useful.

While lockfiles could provide some useful information in the problem you mention, they are often so verbose that lockfile updates are often ignored if CI works fine, defeating that purpose.

[github-actions[bot]]

Hi! This was closed. Team: If this was merged, please describe when this is likely to be released. Otherwise, please add one of the no/* labels.