To shrinkwrap or not to shrinkwrap?

[trusktr]

Normally I don't include package-lock.json in NPM packages, but it seems like it might be a good idea for archetypes, since a single archetype is shared with all projects/packages.

I can foresee a situation where different packages depend on different versions of the archetype, in which case I would guess that builder uses the appropriate archetype for that project?

I suppose builder isn't used in cases where projects are installed as dependencies to other projects -- only in cases where a project is being developed -- except it's possible for some dependencies to be installed from GitHub, in which case the package's build steps need to be ran. In this case, will builder use the right archetype?

Any thoughts on this generally?

[ryan-roemer]

package-lock.json files aren't published, so they don't really have a role for archetypes which are published.

Most of our projects / apps typically use a package-lock.json file or yarn.lock file to lock down deps for the ultimate project's dev team / CI to be sane.

[trusktr]

Oops, I meant, to shrinkwrap or not to shrinkwrap? 😆

Seems like a good idea to shrinkwrap (which is published) in the case of archetypes, because archetypes are not used at runtime, and perhaps builds should always pass exactly as designed without accidental in-range bugs from upstream packages.

Imagine working with a single archetype across hundreds of packages: it might be a hassle to deal with build inconsistencies or bugs across all of them.

Thoughts on that?

[trusktr]

Closing, can keep discussing if needed. I'm gonna try shrinkwrapping, because it's similar to how an application would package-lock build dependencies otherwise, just that now the build dependencies are stored in a separate package.