You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of our projects use (apps and libraries) use yarn for managing NPM dependencies, but when publishing NPM packages doof uses the npm CLI.
This means:
Doof ignores yarn.lock, and may install different versions of dependencies than we use locally / on CI
Doof's npm install may fail when local / CI yarn install succeeds. This happened recently in course-search-utils because of a difference in how npm vs yarn treat incorrectly met peer dependencies. See update linting course-search-utils#61
Neither of these is a big deal. In fact, (1) does not matter at all for pure-JS packages with no build, since transitive dependency versions are controlled by the consumer, not by the library. (In theory, yarn.lock could affect the output of a build step, though.)
But as we update doof, it may be worth considering using yarn for the installation step.
Most of our projects use (apps and libraries) use
yarnfor managing NPM dependencies, but when publishing NPM packagesdoofuses thenpmCLI.This means:
yarn.lock, and may install different versions of dependencies than we use locally / on CInpm installmay fail when local / CIyarn installsucceeds. This happened recently in course-search-utils because of a difference in hownpmvsyarntreat incorrectly met peer dependencies. See update linting course-search-utils#61Neither of these is a big deal. In fact, (1) does not matter at all for pure-JS packages with no build, since transitive dependency versions are controlled by the consumer, not by the library. (In theory, yarn.lock could affect the output of a build step, though.)
But as we update doof, it may be worth considering using
yarnfor the installation step.