refactor(package): Migrate from npm to Yarn#289
Conversation
|
I'd like to share some thoughts on why using Yarn instead of npm is a good thing, at least for the time being:
Last but not least, it was Yarn who pioneered the idea of version locking and package checksums, which speeded up adoption of those concepts in npm. |
package.json
Outdated
| }, | ||
| "scripts": { | ||
| "start": "concurrently \"npm run storybook:run\" \"npm run storybook:openurl\"", | ||
| "start": "concurrently \"yarn run storybook:run\" \"yarn run storybook:openurl\"", |
There was a problem hiding this comment.
With yarn, you don't need to have the run command to execute the script, can just call it by its name yarn storybook:run
There was a problem hiding this comment.
You are right, I'll use the shortcut as suggested.
I tend to prefer an explicit yarn run since CLI docs say:
Note that built-in cli commands will have preference over your scripts, so you shouldn’t always rely on this shortcut in other scripts
but for stuff inside the scripts object, it should be fine.
storybook/webpack.config.js
Outdated
| __dirname, | ||
| '../node_modules/patternfly/node_modules/font-awesome-sass/assets/stylesheets' | ||
| ) | ||
| path.resolve(__dirname, `../${pkg.sassIncludes.patternfly}`), |
There was a problem hiding this comment.
I really like this approach, but this can also be simplified to
Object.keys(pkg.sassIncludes)
.map(oneInclude => path.resolve(__dirname, `../${pkg.sassIncludes[oneInclude]}`))There was a problem hiding this comment.
Thanks Karel, I agree - will do the code change as suggested.
There was a problem hiding this comment.
path.resolve(__dirname, '../sass/patternfly-react'),
- path.resolve(__dirname, `../${pkg.sassIncludes.patternfly}`),
- path.resolve(__dirname, `../${pkg.sassIncludes.bootstrap}`),
- path.resolve(__dirname, `../${pkg.sassIncludes.fontAwesome}`)
+ ...Object.values(pkg.sassIncludes).map(includePath =>
+ path.resolve(__dirname, `../${includePath}`)
+ )|
Looks good, I really like how you solved the import of sass files. |
|
travis is not yet happy... otherwise it looks good to me... |
|
Need to update the Readme, otherwise LGTM. |
|
Addressed Allen's and Karel's review comments, still need to update the README file. |
|
README file updated. Note that with Yarn 1.0 and above, this command: is equivalent to this command: i.e. no need for |
|
Here's a checklist of things to do before merging:
|
cleared all of them just now. |
Thank you @priley86. I'm trying to use a modified version of I'll update this PR (regenerate |
Actually, I was wrong. |
|
Oh well, looks like that even if |
|
I am fine w/ removing the package.lock in favor of yarn.lock. Let me know if you need anything else from me... |
d1ab943 to
3d81218
Compare
|
PR updated to reflect recent changes in
✔️ checked again and everything works as expected. |
@priley86 thanks, this PR should be ready to go, assuming Travis CI passes.
|
|
OK, just realized Travis CI fails because |
39655e9 to
132c155
Compare
Pull Request Test Coverage Report for Build 1157
💛 - Coveralls |
|
Travis CI build is fixed. I also made some changes to 1, CachingUsing applies to (or used to apply to) npm, since npm traditionally didn't have a local package cache. Yarn came with this concept right from the start, in Yarn's terminology it's called "global cache". You can use In response to Yarn, npm introduced the same concept, in npm's terminology it's called "npm cache". Cache location is typically Today, with each of those package managers working with a local package cache, it doesn't make much sense to cache (project-specific) For Yarn specifically, Travis supports that causes everything under 2, Node.js versionYou can specify explicit versions like however this causes Travis to skip reading the 3, Pruning unused packages in
|
|
this looks good to me... and thanks a lot for the yarn notes. Do you mind updating the first commit to be semantic? Since you aren't really impacting downstreams and it is build specific here i think it should be |
|
Thank you @jeff-phillips-18 and @priley86 for reviewing.
Will do 😃
I've checked this PR by Is it OK to use Due to the size of What do you think? (Ultimately, I'm OK with
Travis CI will now use the (single) Node.js version specified in |
|
Just double checking w/ you to be sure before we hit the green button. |
|
OK, makes sense. We don't really need a new release, I'll make the first commit a |
Use https://github.com/imsnif/synp to generate yarn.lock from package-lock.json. Fix node_modules paths. Update Travis config and project docs to use Yarn. Fix patternfly#215
132c155 to
b11be65
Compare
|
thanks @vojtechszocs 🥇 - very much appreciate this! |
Fixes issue #215.
npm => Yarn migration details are outlined below.
1, Populate
node_modulesvia npm2, Generate initial
yarn.lockfrompackage-lock.jsonvia synp3, Project-specific fixes
package.jsonnpm run=>yarn runstorybook/webpack.config.jssassIncludesfrompackage.json(avoid duplication)These fixes reflect the difference between npm-generated vs. Yarn-generated
node_modulesfile structure:node_modules/patternfly/node_modules/font-awesome-sass(nested structure)node_modules/font-awesome-sass(flat structure)4, Update
yarn.lockand fix package checksums if necessary5, Verification
No changes in
yarn.lock- all is good.Storybook components look and work as expected.