<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Oct 14, 2016, at 8:00 PM, Paul Cantrell <<a href="mailto:cantrell@pobox.com">cantrell@pobox.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>On Oct 14, 2016, at 6:42 PM, Daniel Dunbar <<a href="mailto:daniel_dunbar@apple.com">daniel_dunbar@apple.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Oct 14, 2016, at 4:02 PM, Paul Cantrell <<a href="mailto:cantrell@pobox.com">cantrell@pobox.com</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I’m puzzled. If a package’s pinning does not affect any other package that uses it, why should the defaults be different? A library will still suffer from all the “works for me” problems an app might.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Is the rationale that not pinning libraries encourages accidental testing of new versions of a library’s dependencies as they arrive? Or is there another rationale for having different defaults?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I'll defer to this comment (linked from someone else earlier in the thread), which happens to match up with my perspective:</span><br></blockquote><blockquote type="cite"><span> <a href="https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537">https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537</a></span><br></blockquote><span></span><br><span>I took that comment to be an explanation of why a library's lockfile/pinfile should not propagate to other packages that use it. That is clearly the case; such pin propagation would be nonsensical.</span><br><span></span><br><span>My question was not about that, but about why libraries shouldn’t use a pinfile at all, even for their own _internal_ development. All the same “last know good build” concerns apply.</span><br><span></span><br><span>The difference is that testing against that single last known good version set is sufficient for a top-level package, whereas a library should (1) ideally test against multiple valid dependency versions and (2) test often against new versions of its dependencies. I don’t see, however, that this implies that libraries should not have pinfiles at all — just that their release / CI process should not be limited to what’s pinned.</span><br></div></blockquote><div><br></div><div>A few comments down, Yehuda even provides an example of him doing just that with Bundler:</div><div><br></div><div><a href="https://github.com/yarnpkg/yarn/issues/838#issuecomment-253366352">https://github.com/yarnpkg/yarn/issues/838#issuecomment-253366352</a></div><div><br></div><div>But in this case you actually want to maintain *many* lock files, and so it seems fine to require a bit of extra work (passing some flags) to do this. Drifting tests are the better default here. It makes library CI into an alpha-tester, empowering binaries to be more confident in upgrading frequently.</div><br><blockquote type="cite"><div><span></span><br><span>Cheers, P</span><br><span></span><br></div></blockquote></body></html>