React-boilerplate: PR/Discussion: Yarn Support

[amilajack]

There are a large number of install issues related to the installation of npm packages. Yarn claims to guarantee installation safety:

Yarn is able to guarantee that an install that worked on one system will work exactly the same way on any other system.

Think we should give this a go by recommending it as an alternative installation method and committing a yarn.lock file.

[EugeneHlushko]

Hi @amilajack, i just opened a pull #1092

[GGAlanSmithee]

While yarn looks promising, is it not a bit early to recommend it _over_ npm?

Watching the yarn repo, there were about 100 updated issues in the time frame of an hour. Some bug reports, some feature requests, some PRs.

Maybe change the wording in #1092 from;

We recommend to use yarn for dependency management

to

As an alternative to npm, you can use yarn for dependency management, which might make the installation process easier for different platforms

And in time, when yarn is a bit more mature the wording can be changed?

[EugeneHlushko]

Hi @GGAlanSmithee, reword sounds very reasonable lets move this discussion into PR, i will update the wording accordingly.

[amilajack]

And in time, when yarn is a bit more mature the wording can be changed?

Great idea, I definitely agree.

[andykenward]

Does yarn work on travis-ci?

I understand that it is faster on your local and machine and yarn produces a yarn.lock file so all the dependency version are the same even the ones from other packages. But if you are building and deploying via travis-ci etc and it doesnt use yarn and the yarn.lock file, it seems pointless to use yarn at the moment.

[sedubois]

@andykenward see https://github.com/yarnpkg/yarn/issues/920

[amilajack]

@andykenward see https://twitter.com/kentcdodds/status/786282951210262528

[andykenward]

So if yarn is used then the travis.yml needs to be amended? Or perhaps the docs need this defined in them for #1092

[amilajack]

It isnt necessary. For now we should generate and commit both a yarn.lock and npm-shrinkwrap.json files for safer installation so that both npm and yarn users can benefit. We can get significantly faster build times by using yarn but for now I think we should wait for yarn to stabilize.

[gihrig]

Re: npm shrinkwrap - Not a good fit for this project. It's value is lost on the first dependency modification and creates issues with dll build. Npm shrinkwrap is better managed locally by a team that knows what to expect and is prepared to deal with the inevitable issues. see: #873.

We can get significantly faster build times by using yarn

In my experience the difference, either way, is marginal. Yarn has a very long linking dependencies process. Also see this Reddit thread.

So we're left with reliable builds. That's a hard thing to test. We have had a few broken builds due to shifting sub-dependencies beyond our control, so a truly reliable package manager would be desirable. The question is, how to _know_ Yarn actually adds value beyond yet another dependency ?

[peter-mouland]

I'm interested in people saying significantly faster too.
What the time difference, could someone post a few stats to demonstrate?

• npm
• npm w/ shrinkwrap (just for comparison as it sounds like this is unwanted)
• yarn
• yarn with .lock (if shrinkwap is unwanted, i suspect the .lock is too)

cheers

[sedubois]

Yarn always comes with lock, AFAIK. And it will warn you every time, if it detects a shrinkwrap. AFAIK, it's either/or between yarn and shrinkwrap. And personally I'd say that after stabilization phase, yarn shouldn't be an option but just be the only choice.

[gihrig]

Here's a comparison, of sorts, between npm and Yarn. Npm vs Yarn cheatsheet.

[gihrig]

after stabilization phase, yarn shouldn't be an option but just be the only choice.

IMO, Yarn will have to interoperate with npm, not just in this boilerplate, but in the community at large, to be successful. Not only is npm entrenched to the point of "everone knows you just clone and npm install", but yarn replaces such a small sub-set of npm's features. I don't see Yarn replacing npm for a long time.

[sedubois]

Probably my use cases are just too simple, but AFAIK the aim of react-boilerplate is to bootstrap _new_ front-end projects. In that regard, it can come with its own opinionated choice of technologies. If we follow the argument that npm is ubiquitous, we could as well preload react-boilerplate with jquery...

And making the opinionated choice of yarn wouldn't prevent people from using npm anyway, as it's based on a package.json.

[gihrig]

Facebook team blog post introducing Yarn, in case any have not seen it. Discusses reasons for Yarn and scope of use at FB.

[amilajack]

@peter-mouland

I'm interested in people saying significantly faster too.

It really depends on your environment. For people with terrible internet connection, yarn will be much better for them. If you have fast download speeds and a fast machine, yarn might not make that much of a difference. But I think it would be good to cater to both yarn and npm users.

[EugeneHlushko]

@peter-mouland, @amilajack, @gihrig the benefit in installation time of dependencies is indeed there. I have also checked the Npm vs Yarn cheatsheet and can say that in five projects that i have tried yarn vs npm at average rate is Yarn about 4x faster than NPM. I could not see the 8x. But when you think outside of boilerplate initial setup and have this builds maybe on a jenkins UAT, preprod, prod pipelines even 4x is a huge gain.

[mxstbr]

I think we should definitely support yarn. It has enough backing behind it that I'm confident it'll work out all the kinks soon enough for us to start using it. As @gihrig summed up very well, shrinkwrap + yarn.lock is not a good combination, but I don't see any problems with having a yarn.lock file!

[amilajack]

I'm a core contributor of electron-react-boilerplate and we've already fixed an issue simply by recommending yarn:

https://github.com/chentsulin/electron-react-boilerplate/issues/469#issuecomment-254844318

[davej]

My application binary is 5MB heavier with Yarn than it was with npm. This is caused by the non-webpacked stuff in my node_modules folder. Is there a way around this or is it just inherent to using yarn?

edit: Binary === Electron app. Actually posted this in the wrong repo, thought this was electron-react-boilerplate.

[kachkaev]

@davej do you mean that your node_modules directory became 5MB bigger or does this apply to javascripts in /build/? :fearful:

[davej]

My node_modules is ~130MB larger overall before build but most of this is pruned and webpacked so in the end the node_modules in my app binary is only 5MB larger.

[davej]

This seems to be because yarn doesn't dedupe.

[EugeneHlushko]

Hi @davej, Going to play around with that in the evening, might submit a PR

[mxstbr]

Is there anything actionable left to be done here?

[outdooricon]

I think we need to be wary of yarn right now, it can provide a sense of false confidence. See https://medium.com/@boennemann/avoid-yarn-for-packages-and-fully-enjoy-its-benefits-for-application-development-8bdd4deb33cf. Essentially, relying on it can still allow for harmful package conflicts to be introduced since it ignores published npm package shrinkwraps/lockfiles.

[mxstbr]

It says in the TL;DR of that article:

The new yarn package manager is a fantastic tool to install your application’s dependencies.

It just warns against using it for packages. react-boilerplate is meant to build applications with, so I don't see why we should be wary 😊

[EugeneHlushko]

Yeah and also for packages you can use no-lockfile

[outdooricon]

Because if JoeUser installs NewReactComponent into his fresh react-boilerplate project with yarn, and NewReactComponent has a declared reliance on dep-1.1 in it's shrinkwrap (explicitly not dep-1.2 because this is known to break NewReactComponent), then JoeUser now has a non-working NewReactComponent and is frustrated.

[EugeneHlushko]

@outdooricon then your NewReactComponent is broken, rather pin dep in package.json.
Please see this beautiful post describing what you worry about: https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537

[outdooricon]

@EugeneHlushko thank you for that link. That makes me feel much better :+1:

[EugeneHlushko]

You are welcome mate! I am facing some issues with moving older projects to yarn, so i understand your worries :) 0.17 or whatever version number they give it is going to fix my problems that are left so i am looking forward for new release.

[outdooricon]

Lol yes I hear you, I couldn't even get yarn to work with our webpack app until 0.16.1

[yantakus]

There is an issue with using yarn in this project at the moment. When I run yarn add smth, it removes node_modules/react-boilerplate-dlls directory. So we can't install new deps with yarn, maybe move the dir to the root and add it to .gitignore?

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.