freedomjs / freedom

Embracing a distributed web
http://freedomjs.org
Apache License 2.0
512 stars 53 forks source link

npm shrinkwrap #311

Closed agallant closed 7 years ago

agallant commented 8 years ago

I believe it's worth setting all the various freedom repos to use npm shrinkwrap, which basically generates a second npm manifest-ish .json that freezes the versions of all dependencies. Hopefully this helps stop our tests from changing their state underneath our feet.

agallant commented 8 years ago

@willscott any objection if I also npm shrinkwrap freedom/flavors prior to cutting releases? Details: https://docs.npmjs.com/cli/shrinkwrap

I may lock down dev dependencies as well (which is not default behavior, but probably appropriate for us). Basically this just generates an npm-shrinkwrap.json file that is used in place of package.json for installing dependencies. For development we can still bump versions in package.json and then rerun npm shrinkwrap when we're ready to release.

willscott commented 8 years ago

i would ideally do this in 3 steps:

  1. make a release with current set of changes.
  2. update dependencies to current versions as much as possible. if small things break them, lets face them. Since we aren't currently shrink wrapped, many may already be ahead of what was originally intended. 3.once dependencies are largely current, then shrink wrap, since that action then means we need to do extra work in keeping our dependencies up to date, i'd prefer not to codify our 'already 6 months behind' state more than we need to.
agallant commented 8 years ago

K, agreed on bumping dependencies before shrink wrapping, and I'm fine with doing that after release if preferred (since the main goal is to facilitate development w/more reliable CI).