Distribute Fable packages too through npm?

[alfonsogarciacaro]

Fable 2.1 will be distributed through npm #1639, removing the need of calling a dotnet cli tool. At first, I thought the packages should still be distributed through Nuget for better compatibility with F# tooling but given that @ncave has published a JS version of the compiler (see for example #1648) and given that in the near future we may give users the possibility to switch between the dotnet or js versions of the compiler, I'm reconsidering the possibility of experimenting again with npm distribution for Fable libraries.

Differences with Fable 0.7

• Libraries won't be precompiled, all sources will be compiled at first as it happens now
• We should add a command to inject .dll references in the .fsproj file instead of forcing users to do so. For this, the compiler must scan the node_modules for Fable packages, so we need a way to mark them (possibly a file next to package.json).

Potential benefits

• In Fable-only projects, users only need to deal with one package manager. This can be a good point for users coming from JS.
• Fable packages could have npm dependencies (and install them automatically!)
• We wouldn't need to copy sources from Nuget cache to a .fable folder to avoid Webpack module resolution issues.
• Simplified publishing process? I find managing npm packages much easier than Nuget, but I guess it depends on the personal experience.

Potential problems

• Users will need to remember to add the special command to inject .dll references in a "postinstall" script in their package.json
• Touching the .fsproj is risky
• Assembly reference issues?
• npm may try to install package dependencies as sub dependencies as it happened with Fable 0.7. To avoid this, we'll have to use peerDependencies always (or can we create a crawler to detect these cases?), but this is cumbersome for the user as npm doesn't install peerDependencies automatically anymore.

Please give your feedback and other problems you may foresee. cc @ncave @MangelMaxime @Zaid-Ajaj @et1975 @forki @inosik

[Nhowka]

Fable packages could have npm dependencies (and install them automatically!)

That one has potential to be awesome. Would it be fine to have both npm and nuget dependencies?

[et1975]

Just saying...

Benefits < Problems + Differences

We still need to have dotnet installed, which comes with package management, so it's not like we're forcing people to install an extra tool.
I'm also not convinced that fable dependencies can have a good story with JS dependencies, peer or otherwise - I bet no specific Fable.React version represents any particular ReactJS 100% correctly, conversely I can use Preact instead, so is it really worth forcing this relationship?
Also these aren't the early days, there are probably hundreds if not thousands of projects, howtos and tutorials. Do you really want Fable ecosystem to look like the rest of JS, where you can't be sure of anything you find that's not days-fresh?
I still have npm packages I haven't migrated from pre-1.x days to nuget, and I can guarantee there will be even more fragmentation if you switch the method again.

[ncave]

@alfonsogarciacaro First of all, by all means +1 for tooling stabilization and simple tooling story.

While it does sound interesting to be able to use different package managers, I'm not sure about updating the .fsproj, perhaps updating the paket.dependencies can work. But it could be a lot of maintenance cost to take on supporting another package manager, and perhaps @et1975 has a point there about the fragmentation.

[forki]

Regarding npm dependencies - if that's a serious concern, then we could also put meta data into the nupkgs and paket can add the npm package deps to the project. Then you only need to call yarn or npm after paket install. Just as another option.

[MangelMaxime]

I think we should stay with dotnet dependencies because this is what the IDE knows and also paket & co are already doing an amazing job managing the deps for us.

Also as @et1975 said, we will have even more fragmentation. Another point, is that I don't think all the package have been migrated to Fable 2 by their authors so imagine if they had to move to npm ?

Regarding npm dependencies - if that's a serious concern

I think it can be for projects like Fulma for example. This is not mandory if in the documentation we mention which version of the JS lib is supported etc. but it can make people life easier I think. I so some people coming from .Net installing Fulma and saying it's not working because they didn't know they had to install Bulma too.

In Have langauge, when writing an extern we put a special macro in the binding like npm.Package.Require<"bcrypt","^3.0.2"> and then on the first execution if the macro doesn't find bcrypt in the packge.json it will had it.

So you can then, run npm install and yarn install and be ready to go.

I think this is similar to what @forki propose and I am more for this solution.

[forki]

Just to remind you: if there is anything specific that you guys think paket would need to make life easier for fable users or fable package authors - I'm happy to look into that and will try to make it happen. On the other hand: if there is substantial benefit from moving things back to npm - I'm not opposed to that. I'm already fine with using yarn - but we should find a solution with minimal confusion. Right now I have react SSR in my projects and they reference Thoth.net and js versions. It will be weird to reference these in different ways Am Do., 22. Nov. 2018, 07:43 hat Maxime Mangel <notifications@github.com> geschrieben:

…

I think we should stay with dotnet dependencies because this is what the IDE knows and also paket & co are already doing an amazing job managing the deps for us. Also as @et1975 <https://github.com/et1975> said, we will have even more fragmentation. Another point, is that I don't think all the package have been migrated to Fable 2 by their authors so imagine if they had to move to npm ? Regarding npm dependencies - if that's a serious concern I think it can be for projects like Fulma for example. This is not mandory if in the documentation we mention which version of the JS lib is supported etc. but it can make people life easier I think. I so some people coming from .Net installing Fulma and saying it's not working because they didn't know they had to install Bulma too. In Have langauge, when writing an extern we put a special macro in the binding like npm.Package.Require<"bcrypt","^3.0.2"> and then on the first execution if the macro doesn't find bcrypt in the packge.json it will had it. So you can then, run npm install and yarn install and be ready to go. I think this is similar to what @forki <https://github.com/forki> propose and I am more for this solution. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1649 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNIMF4D2Imbyh0fJHzev-Son9MT4bks5uxkergaJpZM4YuSpc> .

[alfonsogarciacaro]

Thanks a lot for the feedback! You're right this move can bring a lot of confusion to users and authors for little benefit, I got a bit too excited 😅 Ok, let's close this issue and maybe open another one in Paket about the possibility of adding npm dependencies.