Publish a lock file as part of GH releases

Reasoning:

• lock files are useful for reproducible builds and debugging
• some people find lock files annoying, esp. when maintaining libraries

To get the best of both worlds, it would be nice to keep a lock file, but not make it a part of the repo nor a part of the npm published package.

So I’d suggest:

• when creating a GH release
• if there is a package-lock.json or an npm-shrinkwrap.json (or a yarn.lock?) - back it up
• create an npm-shrinkwrap.json (incl. dev deps) and include as an artifact
• restore the previous lock file (or delete, if none existed), so that other plugins are unaffected

I think it would be a good default, with an opt-out, but opt-in is probably also better than nothing. Not sure if there’s a way to have this as a recipe (if there is reluctance to have it built in)? Maybe create it in postpack?

Happy to PR, if an approach can be agreed.

[pvdlg]

Thanks for the thorough explanations @dominykas!

I think your use case is not common enough to implement it as default behaviour in semantic-release. You can however achieve that with the current plugins:

• Use @semantic-release/exec to generate your npm-shrinkwrap.json and move it in a temp folder
• Use the the assets option of @semantic-release/github to add it to the GH release

[dominykas]

Thanks, I understand. I was thinking of a wider application for reproducible build tooling, but I guess we’ll have to wait and see.

I’m also reluctant to tinker with plugins defaults (not sure why, just doesn’t feel comfortable, maybe cause so much of default functionality depends on that), but I haven’t looked at shared configs, so maybe there’s scope for easy setup that way.