You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've resisted the idea of committing the package-lock.json file out of concern that it would cause headaches during merge and rebases, especially for long-standing PRs (which we have enough of to be of concern.
But experience with a file with a similar profile (refcache.json) has proven to be not as bad as I expected. Given that, I'd like to suggest that we give it a try: i.e., commit package-lock.json. We should probably agree on the (maleable) convention that only site maintainers and approvers should update the lock file.
Of course, after a trial period, we can always fall back to our current situation, or even pushing things further and making package.json into a substitute lock file by pinning packages to exact version, which is what we do currently for Hugo.
Pros of committing the lock file: it can help us optimize our CI, and simplify some workflows. No extra lock file to maintain since it gets generated dynamically as needed.
Cons: as mentioned before, it can complicate merges and rebases, esp. for long-standing PRs. Another con is that we need to "maintain" the lock file.
Thoughts?
The text was updated successfully, but these errors were encountered:
Let's give it a try. I think we might be better of with it. If we run into lots of issues with it with merging and rebasing we still can write yet another fix command to clean the package-lock and update it with the current version
I've resisted the idea of committing the
package-lock.json
file out of concern that it would cause headaches during merge and rebases, especially for long-standing PRs (which we have enough of to be of concern.But experience with a file with a similar profile (
refcache.json
) has proven to be not as bad as I expected. Given that, I'd like to suggest that we give it a try: i.e., commitpackage-lock.json
. We should probably agree on the (maleable) convention that only site maintainers and approvers should update the lock file.Of course, after a trial period, we can always fall back to our current situation, or even pushing things further and making
package.json
into a substitute lock file by pinning packages to exact version, which is what we do currently for Hugo.Pros of committing the lock file: it can help us optimize our CI, and simplify some workflows. No extra lock file to maintain since it gets generated dynamically as needed.
Cons: as mentioned before, it can complicate merges and rebases, esp. for long-standing PRs. Another con is that we need to "maintain" the lock file.
Thoughts?
The text was updated successfully, but these errors were encountered: