Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: Installing dependencies with yarn #31

Closed
wants to merge 13 commits into from

Conversation

rkostrzewski
Copy link
Collaborator

Changes npm install to yarn add when creating app & yarn is available as global command (similar to how create-react-app works). Faster install, progressive enhancement, yada, yada, yada.

Your next Preact PWA starts in less than 30 seconds. 😉

Cross-platform compatibility verified on MacOS & Windows 10.

lukeed
lukeed previously requested changes May 21, 2017
Copy link
Member

@lukeed lukeed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Perhaps we could refactor away the npm() helper entirely & run everything through spawn()?

@rkostrzewski
Copy link
Collaborator Author

Good call.

Also npm-install-loader possibly could use yarn not end up with missing dependencies in yarn.lock file.

@@ -66,13 +66,12 @@ export function writeJsonStats(stats) {
jsonStats.modules.forEach(normalizeModule)
jsonStats.chunks.forEach(c => c.modules.forEach(normalizeModule))

return fs.writeFile(outputPath, JSON.stringify(jsonStats))
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sneaky refactor 👣

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well-earned, I'd say ;)

@rkostrzewski
Copy link
Collaborator Author

rkostrzewski commented May 22, 2017

@lukeed removed npm. but this should still be on hold as postcss-modules-resolve-imports has just upgraded to postcss@6 and yarn installs it as peer dependency and #22 happens all over again fixed.

I've looked into npm-install-loader and I have no idea what does it do.
Firstly, it does not install dependencies (aka other loaders) when other are not present and webpack returns error - I guess that's why #21 was made.
Furthermore, returning early from loader with error doesn't break the build & isn't shown earlier. I've tried following:

let callback = this.async();
callback("Hey I'm an error in a loader!")

What's the point of the loader?

package.json Outdated
@@ -94,7 +94,7 @@
"babel-register": "^6.24.1",
"copy-webpack-plugin": "^4.0.1",
"cross-spawn-promise": "^0.10.1",
"css-modules-require-hook": "^4.1.0-beta",
"css-modules-require-hook": "^4.0.6",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the culprit of #22 and issues with yarn. I don't know why beta version was used - last stable version works fine for prerendering (at least for the examples). Don't know if that's ok.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooh cool. I'll check this out!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heads up - i merged @lukeed's PR without seeing this first.

@lukeed lukeed mentioned this pull request May 22, 2017
@thangngoc89
Copy link
Collaborator

thangngoc89 commented May 23, 2017

I finished review this PR, read several articles on hacker news and it's still installing devDeps. So 👍 👍

@@ -83,7 +84,7 @@ export default asyncCommand({

spinner.text = 'Initializing project';

await npm(target, ['init', '-y']);
await spawn('npm', ['init', '-y'], { cwd: target, stdio: 'ignore' })
Copy link
Member

@developit developit May 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol this is what it used to be 😆

does Yarn not include an init functionality like npm's?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@developit yes it does

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

future thing to do might be to move the which check up and use yarn here too. For now anyone running yarn would have npm installed anyway.

developit
developit previously approved these changes May 25, 2017
@@ -66,13 +66,12 @@ export function writeJsonStats(stats) {
jsonStats.modules.forEach(normalizeModule)
jsonStats.chunks.forEach(c => c.modules.forEach(normalizeModule))

return fs.writeFile(outputPath, JSON.stringify(jsonStats))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well-earned, I'd say ;)

if(isDev) {
args.push('-D')
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can slim this down by moving the .filter(Boolean) into install, but I'll just slip that in post-merge :)

@developit
Copy link
Member

developit commented May 25, 2017

@rkostrzewski regarding npm-install-loader - it's less automatic than you're thinking. All it does is install missing dependencies from a manually specified list before continuing to the next loader. If the deps are installed it's a no-op, otherwise it will shell out to install them and then continue.

The use case is: you created a new project and added a .less file. Running compile hits the file and just installs less-loader and friends for you, rather than bailing out. It lets us support typescript/less/sass/etc and configure them internally, but avoids installing them for everyone who may not need or want them in a project.

@developit
Copy link
Member

@rkostrzewski should we move install() into its own module and import that for use in npm-install-loader? I kept that loader internal for changes like these - we could rename it to dependency-install-loader and have it use npm/yarn same as this PR does.

@rkostrzewski
Copy link
Collaborator Author

@developit I don't think it works at all. The less example might work because less-loader is included in preact-cli deps.
Running:

preact create preact-app && cd preact-app
mv ./style/index.css ./style/index.scss
npm run build

Yields:


> [email protected] build /Users/rkostrzewski/GitHub/preact-app
> preact build

./index.js
Module not found: Error: Can't resolve 'sass-loader' in '/Users/rkostrzewski/GitHub/preact-app'
resolve 'sass-loader' in '/Users/rkostrzewski/GitHub/preact-app'
  Parsed request is a module
  using description file: /Users/rkostrzewski/GitHub/preact-app/package.json (relative path: .)
  after using description file: /Users/rkostrzewski/GitHub/preact-app/package.json (relative path: .)
    resolve as module
      looking for modules in /Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules
        using description file: /Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/package.json (relative path: ./node_modules)
        after using description file: /Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/package.json (relative path: ./node_modules)
          using description file: /Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/package.json (relative path: ./node_modules/sass-loader)
            as directory
              /Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules/sass-loader doesn't exist
            no extension
              /Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules/sass-loader doesn't exist
            .js
              /Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules/sass-loader.js doesn't exist
            .json
              /Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules/sass-loader.json doesn't exist
      looking for modules in /Users/rkostrzewski/GitHub/preact-app/node_modules
        using description file: /Users/rkostrzewski/GitHub/preact-app/package.json (relative path: ./node_modules)
        after using description file: /Users/rkostrzewski/GitHub/preact-app/package.json (relative path: ./node_modules)
          using description file: /Users/rkostrzewski/GitHub/preact-app/package.json (relative path: ./node_modules/sass-loader)
            as directory
              /Users/rkostrzewski/GitHub/preact-app/node_modules/sass-loader doesn't exist
            no extension
              /Users/rkostrzewski/GitHub/preact-app/node_modules/sass-loader doesn't exist
            .js
              /Users/rkostrzewski/GitHub/preact-app/node_modules/sass-loader.js doesn't exist
            .json
              /Users/rkostrzewski/GitHub/preact-app/node_modules/sass-loader.json doesn't exist
[/Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules/sass-loader]
[/Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules/sass-loader]
[/Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules/sass-loader.js]
[/Users/rkostrzewski/GitHub/preact-app/node_modules/preact-cli/node_modules/sass-loader.json]
[/Users/rkostrzewski/GitHub/preact-app/node_modules/sass-loader]
[/Users/rkostrzewski/GitHub/preact-app/node_modules/sass-loader]
[/Users/rkostrzewski/GitHub/preact-app/node_modules/sass-loader.js]
[/Users/rkostrzewski/GitHub/preact-app/node_modules/sass-loader.json]
 @ ./index.js 2:0-17
 @ ./~/preact-cli/lib/lib/entry.js
 @ multi ./~/preact-cli/lib/lib/entry

Even tough sass-loader & node-sass are included in npm-install-loader config. That's why I was asking.

I'll try to fix it along while adding yarn to it.

@rkostrzewski
Copy link
Collaborator Author

@developit Yeah, I think it won't work and if I'm not wrong there's no way to fix this.

Long story short, webpack verifies if all loaders are present before attempting to compile files. This happens in NormalModuleFactory and occurs before compiler starts compiling & any loaders are run (source + empirical tests). Seemed like a cool feature tough 😢

@developit
Copy link
Member

developit commented May 26, 2017

Darn. I had figured pitching phase would circumvent that. One other option would be to use a proxy loader - that internally does the installation and then calls out to less-loader.

@rkostrzewski
Copy link
Collaborator Author

Yeah, proxying the loader would work for normal loaders. However it would be hard to make it work with pitch loaders and the solution looks very hacky.

@hassanbazzi
Copy link
Member

@rkostrzewski I think you can just fix that in webpack by passing a resolveLoader object. I had the same issue happen to me before

@rkostrzewski
Copy link
Collaborator Author

@hassanbazzi I don't quite get how to use resolveLoader in this scenario. If I alias loader to another module which exists won't that be used by webpack later on?

@rkostrzewski rkostrzewski dismissed lukeed’s stale review June 7, 2017 21:20

Stale review & removed npm() helper

@lukeed
Copy link
Member

lukeed commented Jun 7, 2017

rkostrzewski dismissed lukeed’s review I guess now we're even 😆

@reznord
Copy link
Member

reznord commented Jun 28, 2017

@rkostrzewski Travis tests are failing because of an eslint error. Can I go ahead and fix that error?
It is because const npm = ... here is not being used anywhere !!

But there is this error - https://travis-ci.org/developit/preact-cli/jobs/247829570#L1925-L1926 which I didn't understand.

What is this about?

@rkostrzewski
Copy link
Collaborator Author

@reznord sure go ahead. As for the other error I think there's some problem with async commands. I think about spiking the tesrs with console.log to determine where the error is (seems like output folder doesn't exist sometimes on first test)

@rkostrzewski
Copy link
Collaborator Author

Also @lukeed has proposed installing with tarn using a switch as new npm has same capabilities as yarn with which I totally agree.

@thangngoc89
Copy link
Collaborator

thangngoc89 commented Jun 28, 2017

as new npm has same capabilities as yarn

@rkostrzewski I'm not agree with this. Yarn offers much more besides speed and lock file. IMHO, if someone installed yarn it mean that they want to use it.

How about an interactive question to ask which dependency manager to use?

@reznord
Copy link
Member

reznord commented Jun 28, 2017

@rkostrzewski you have to make the changes, since it is a branch in your local repo :P

@reznord
Copy link
Member

reznord commented Jun 28, 2017

Also @lukeed has proposed installing with tarn using a switch as new npm has same capabilities as yarn with which I totally agree.

Well, consider this case where you have enabled npm install for running tests. That would just take an eternity to install the node_modules. Considering the same situation with yarn, it caches all the packages and it hardly takes a minute to install the packages.

@thangngoc89
Copy link
Collaborator

Well, consider this case where you have enabled npm install for running tests. That would just take an eternity to install the node_modules. Considering the same situation with yarn, it caches all the packages and it hardly takes a minute to install the packages.

@reznord try npm@5 ;)

@reznord
Copy link
Member

reznord commented Jun 28, 2017

@thangngoc89 I did try, I have to say that it is faster than previous versions but still not close to yarn.

@thangngoc89
Copy link
Collaborator

@reznord It's faster than yarn in my exeperience. Maybe your npm@5 global cache is empty? But anyway, see my comment above for my opinion

@lukeed
Copy link
Member

lukeed commented Jun 28, 2017

Chiming in: Yes, I think yarn usage should not be used by default if it is found. Suppose @thangngoc89 had once been a Yarn user, switched to npm@5 but forgot to uninstall Yarn. With this setup, we would find his (old,outdated) Yarn binary and use it.

We should use a --yarn flag because (1) it's technically not an official package manager, (2) it may not always be wanted, (3) presence of a flag is faster & easier to check, plus (4) when the flag is present, we don't have to make any assumptions about whether or not to use it.

Just my 2¢ 😉

@thangngoc89
Copy link
Collaborator

@lukeed That seems ok to me

@reznord
Copy link
Member

reznord commented Jun 28, 2017

Agreed on this !!

@developit
Copy link
Member

Oooh very good point @lukeed, I'm for the --yarn flag if we want to support installing via it.

@rkostrzewski
Copy link
Collaborator Author

rkostrzewski commented Jul 1, 2017

@reznord what should I do with this in light of #155? Should I close this and we'll continue with --yarn flag there?

@lukeed
Copy link
Member

lukeed commented Jul 1, 2017

@rkostrzewski Unless I'm hugely mistaken, it doesn't look like that PR is going with a --yarn flag either.

@rkostrzewski
Copy link
Collaborator Author

@lukeed yeah I've meant continuing as in developing --yarn flag there

@reznord
Copy link
Member

reznord commented Jul 13, 2017

A fresh new PR available for yarn support #225 Closing this.

@reznord reznord closed this Jul 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants