package-lock.json lockfileVersion mismatch

[imnasnainaec]

The extension templates (https://github.com/paranext/paranext-extension-template/blob/main/package-lock.json and https://github.com/paranext/paranext-multi-extension-template/blob/main/package-lock.json) have "lockfileVersion": 2,, whereas paranext-core (https://github.com/paranext/paranext-core/blob/main/package-lock.json) has "lockfileVersion": 3,.

[tjcouch-sil]

Looks like an npm dev explained that you can use npm i --lockfile-version 3 to upgrade the version automatically. I tried it on the multi-template repo, and it seemed very successful; there were only two sections of changes: the lock file version increased to 3, and dependencies was removed. My understanding is that the only difference between the two versions is that dependencies is removed, so that makes sense.

The trouble is not knowing what would happen when people are updating their extensions from the templates. Presumably, this update will cause merge conflicts in package-lock.json. Normally, you can resolve merge conflicts in that file with npm i; easy. However, I don't know what would happen if the lock file versions are different in the merge conflicts. We need to test this before we merge any PRs updating the lock file.

Test by updating from templates locally on one of our multi-template repos to see what it takes to get it merged and updated. To test updating extensions from a branch other than main, you can change the MULTI_TEMPLATE_BRANCH and SINGLE_TEMPLATE_BRANCH in lib/git.util.ts to the branch name. If it just takes an npm i after the merge conflicts appear and everything works, that's great. But I wonder if you'd need to set --lockfile-version 3 when fixing the merge conflicts as well.

We need to know if you need to specify --lockfile-version 3 when merging so we can announce this special update requirement and put it in the commit message for extra discoverability.