fable-compiler / Fable

F# to JavaScript, TypeScript, Python, Rust and Dart Compiler
http://fable.io/
MIT License
2.92k stars 300 forks source link

Distribute Fable packages too through npm? #1649

Closed alfonsogarciacaro closed 5 years ago

alfonsogarciacaro commented 5 years ago

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

Potential benefits

Potential problems

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

Nhowka commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/fable-compiler/Fable/issues/1649#issuecomment-440928902, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNIMF4D2Imbyh0fJHzev-Son9MT4bks5uxkergaJpZM4YuSpc .

alfonsogarciacaro commented 5 years ago

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 :sweat_smile: Ok, let's close this issue and maybe open another one in Paket about the possibility of adding npm dependencies.