it's built-in and part of the workflow. `npm-shrinkwrap.json` is another set of commands and opt-in. `yarn` uses it automatically
-
-
IMHO this is the single biggest contribution of yarn: workflow. Speed is secondary.
1 reply 0 retweets 7 likes -
Replying to @rauchg
I think we should think carefully about how this effects the ecosystem before jumping onboard. For apps, locking is great.
2 replies 1 retweet 5 likes -
But I don't think we should lock modules. Then, if I publish a patch, dependents wont inherit automatically.
1 reply 1 retweet 1 like -
I patch "buffer" all the time and "browserify" gets the fixes for free. If it had a lockfile, then another PR would be required.
3 replies 2 retweets 3 likes -
Replying to @feross
worth noting that yarn only uses the lockfile at the root: it doesn't consult the ones pulled in with dependencies.
1 reply 0 retweets 0 likes -
Replying to @terinjokes @feross
as a result, you can commit a lockfile for your libraries test environment, without enforcing the same on end users.
1 reply 0 retweets 1 like -
Replying to @terinjokes @feross
which means you won’t be testing configurations your users might get ¯\_(ツ)_/¯
2 replies 0 retweets 1 like -
Replying to @janl @terinjokes
Exactly. Not ideal to have a discrepancy between how installs happen for devs vs. users of a package
1 reply 0 retweets 0 likes -
I suppose most people don't "rm -rf node_modules && npm install && npm test" like I do before publishing, but they should
2 replies 1 retweet 1 like
yeahhh, I usually let CI handle this for me butttt stilllllll - good point @janl @terinjokes
-
-
*batman theme plays* nananananananananannanananana Trade-Offs!
1 reply 0 retweets 1 like -
That's true. CI saves the day again!
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.