(Suggestion) Check package-lock.json into git

[AleksandrHovhannisyan]

Unrelated to 11ty itself, but while working on a branch, I noticed that package-lock.json is gitignored. I'm not sure if there was a reason for doing this originally, but I think we should check it in to ensure that everyone's always installing the right package versions. Another benefit is that it makes it more obvious what the preferred package manager is for the project; others might use yarn and accidentally commit their yarn.lock (which isn't gitignored).

[glasswings]

I'm drafting a change. The pros/cons I have in mind are

Pros

• Less opportunity for "But it worked on my machine!" confusion
• New contributors can check out a build that passed CI and use it to verify that their build environment works
• Reliable git bisect (in history after the change)

Cons

• If a release ships a specific lockfile, users can get stuck with old bugs instead of new ones (until they npm update)
• If a release doesn't ship a specific lockfile, this adds complexity to the release procedure
• New contributors need a bit of instruction
• A bit more history noise, and a tiny bit of policy saying when/how to update versions

IMO the pros are really significant. I was just looking at Jekyll: they don't track their Rubygems lock, and instead they have Earthly and a Docker plugin for VS Code - I didn't want to install all that stuff even though I was having problems.

I think it's better to leave releases unlocked. The advantages are pretty specific to development or CD.

I'll work on the new-developer experience next. I don't know enough about the CI system yet to propose modifications. I do know we're intended to run npm ci instead of npm i - but that will fail if releases are tested the same way.

History: the ignore line was added by a4cba48

[zachleat]

This is shipping with 3.0.0-alpha.19 and 3.0.0-beta.2

[zachleat]

#3100