Use embedded version of yarn

[MangelMaxime]

Description

We are using an embedded version of paket.
@kunjee17 asked if we could use an embedded version of yarn too.

I know that we can download yarn.js file directly. see here

I think it's a good idea, as we don't force the user to install it and also different project can use different version of yarn :)

/cc @alfonsogarciacaro @forki

[alfonsogarciacaro]

Yeah, I was considering something like that. It'd be nice to have both Paket and yarn embedded in the apps so yarn is not a hard requirement, but there are two main problems for that:

• The yarn commands would become uglier, like: node .yarn/yarn.js install (or maybe npm run yarn -- install). We could use scripts but then we have the usual problem of Windows/unix compatibility.
• All yarn guides, documentation... assume yarn is installed globally.

[MangelMaxime]

Installing it globally is a bad practice in my opinion :)
As said, developer can't be sure they have the need of the same version of yarn into all their projects.

After, it's to be discuss and perhaps to users.

Also, you said yarn isn't a hard requirement and we had this discussion on elmish templates. Conclusion was if you lock the version with paket or yarn you should lock them with the other too. Otherwise, you can result in strange behaviors.

[alfonsogarciacaro]

Those are problems that also affect JS projects, but the yarn team decided to go for global installations. In my personal opinion we should try to go with the flow as much as possible, so users can take advantage of all the existing documentation, community support, etc, and don't be too imaginative for Fable projects. But if you can think of a nice and simple way of embedding yarn and call it nicely I'm not opposed to the idea 😄

[MangelMaxime]

Could it make sense to add an option into fable cli like: dotnet fable yarn-run

And we would have specify the version of yarn somewhere. So fable check if he already installed this version for the local project. If not take it from somewhere (github, yarn website) and then run yarn automatically to do yarn install.

Idea is to hide yarn into dotnet/fable as we do for paket.

I know paket is doing all the stuff on dotnet restore but perhaps we can have a middle way for yarn. Waiting to have a better way handling this case :)

What is your opinion guys ?

[kunjee17]

Hmmm, this is interesting idea. Earlier we are required to maintain sequence of npm install / yarn install and then dotnet restore as packages are coming via npm install. But as it is not requirement. So, we can use dotnet restore to install yarn and also yarn dependency. I guess @forki is doing it in his sample. Installing everything at once. And then run it. It will take away all the problem of multiple install.
Means dotnet-fable restore and then dotnet-fable run start or may be only last command to do it all. I don't know the feasibility part but I am just throwing an idea over here.

[mike-morr]

Other projects I have seen like the angular/cli, checks for yarn and uses it if available and falls back to npm. We could do the same, but add a warning saying "To get the best experience we recommend using yarn from http://yarnpkg.com to take advantage of the lock files we provide."

[johlrich]

Regardless of local vs global usage, what about msbuild tasks that make it so users would only need the dotnet restore to get all packages and cut down on the steps needed to get going, something like https://github.com/natemcmaster/Yarn.MSBuild

[alfonsogarciacaro]

@johlrich That looks very interesting! Do you know what it does if yarn is not installed? Can you check if it works with the fable template?

[johlrich]

It does work with the fable template. Here's some comments based on trying it out:

• The nuget package for that bundles a version of yarn with it, so it works without yarn installed.
  • It will default to the bundled version if found, then check for a property setting an explicit path if not, then try path last. May put extra burden on template manager to bump with yarn.
  • I wondered if it made more sense for the msbuild task to try and use path first and if not, then fallback to dist.
  • As an aside, the bundling for that project is scripted and just needs a version number changed in a standalone file and a build+publish, which looked easy to manage.
• The package currently calls yarn install on dotnet build. I think this would make more sense being on dotnet restore like paket does.
• The package currently calls yarn clean when dotnet clean is called. This doesn't seem right considering that dotnet clean is intended to clean build artifacts and yarn clean seems to be dealing with cleaning out unneeded files in your node_modules folder, not build artifacts. It also creates a .yarnclean file when you run it, which may confuse users. https://yarnpkg.com/lang/en/docs/cli/clean/

Based on that review I don't know if we'd want to use that package without first addressing some of these things, but I do think it at least proved that the idea of including it in the msbuild/dotnet cli workflow was worth pursuing to simplify the initial experience.

[MangelMaxime]

We can close as user can now use npm5 and yarn.

Also, for templates we can give the choice to the user. (Will be available soon on Elmish ones)