Create Fable.Import package

[alfonsogarciacaro]

@ncave has proposed something very sensible here. Quoting:

Does it make sense in your opinion to move all the jsNative imports out of Fable.Core into their own assembly, to lower the release churn on Fable.Core?

It does make a lot of sense. In Fable first versions I put everything in a single module because referencing .dlls was done manually and it was cumbersome. But now we have Paket! So adding dependencies it's just a matter of adding the name in the paket.dependencies/paket.references files. Fable.Core is tightly coupled with the Fable.Compiler, but Fable.Import types are not, so splitting them will allow us to update the bindings more frequently without affecting the the pair Fable.Core/Fable.Compiler.

The only problem is Fable.Core.JsInterop.importDynamic which has a dependency on Fable.Import.JS.Promise, I guess we'll have to move it. And there's another question. Should we have a single package for JS, Browser and Node bindings or rather three different packages?

And while we're at it, Fable.Core contains both helpers for Fable developers and the AST the Fable.Compiler uses. At first I thought this would make it easier to write plugins, but it seems not many users have taken advantage of it. I always wonder if it's better to move the AST to Fable.Compiler though a) this probably won't remove the Fable.Core/Fable.Compiler coupling, and b) now that libraries bundle both code and assembly, it should be possible for them to embed their own plugins (Fable.React did that before). Atm the AST is a bit complicated but if we write a nice DSL to generate it, that could open interesting possibilities.

[ncave]

@alfonsogarciacaro Fable.Core.Extensions.fs also has dependency on Fable.Import.JS.Promise. We can either keep the whole Fable.Import.JS or just the Promise/PromiseLike portion of it, which is unlikely to change.

[MangelMaxime]

I think this would be a good idea.

I would go for three different pacakges but users might be confused about the need of importing JS + Browser and JS + Node. As in JavaScript world we always say just Browser or Node env.

[inosik]

I think Fable.Import.JS should stay in Fable.Core. Fable targets JS after all, so it makes sense that the core language stuff is available without any extra packages.

[Zaid-Ajaj]

Time to make seperate repos for Fable.Node and Fable.Browser?

[alfonsogarciacaro]

I was thinking to put all the bindings in https://github.com/fable-typed/types to build on @mizzle-mo's work :)

[et1975]

Can someone ELI5 this: what's the benefit of the monorepo? What's wrong with repo per lib?

[alfonsogarciacaro]

Ok, I'll give it a go ;)

• We already tried the repo per binding solution, it doesn't seem to have worked very well. So let's follow DefinitelyTyped (the closes example to what we want to do) and try the mono repo approach now.
• Visibility: This is actually the main reason, and it seems to have worked well for DefinitelyTyped. It helps users find the available bindings easier and apparently it also appeals contributors who can have more publicity for their bindings.
• Maintenance: I know this is debatable and it depends on the person, personally I find the mono-repo approach easier when the projects are strongly related and share common build tasks. I already have several bindings scattered in different repos and I forgot about most of them. At the beginning I was hoping having each binding in a different repo would help contributors get ownership, but I don't know any example of a popular and well maintained Fable binding so far. Having everything in a single repo makes it easier for a team of contributors to keep a uniformed style, respond to issues (even if they didn't create a specific binding), etc.
• Automation: Our goal is to have most of the bindings automated so they can be easily updated from DefinitelyTyped (as FunScript did originally). A mono repo should be a better fit for this.
• Momentum: @mizzle-mo, @jgrund and others are contributing a lot to the bindings recently so I think it's good to build on their work instead of breaking everything apart again. (Of course, I'd love to hear also their opinion about putting everything in the same repo.)

Please note I'm talking about pure bindings (in Typescript parlance, declarations): type definitions with no code. These will be distributed only as .dlls (without source files) to speed up compilation. Other libraries more involved including helper code (like Fable.React) should probably go in their own repos.

[et1975]

I wrote a lengthy reply, but screw it... I can't behind any of this, but it's irrelevant. One thing I will say is: ownership matters - for some of us this not just a hobby. I've seen a bindings we've contributed early on disappear because the repo in question was a kitchen sink managed by a committee and it's just not acceptable from business continuity perspective.

[alfonsogarciacaro]

Of course I won't be pointing a 🔫 at anybody to force them push their bindings to a mono-repo 😉 I see compatible having a single repo with Fable-community maintained bindings while other contributors publish and maintain packages on their own.

It's possible that right now the fable-typed repo contains some bindings created by external contributors. I totally agree these bindings should be removed if the original creators prefer to keep them in their own repos.

[mike-morr]

Totally agree with @alfonsogarciacaro. The idea was to put them all together and try to build community around it while giving consumers a primary place to look first. I definitely don't want to turn anyone off of the idea. Perhaps the better approach is to delete all the 3rd party stuff and ask them politely. I didn't change any of the authors in the files though, and have no intention of doing so. Right now I see it more as a fork to aggregate them, but I definitely don't want to upset anyone, especially @et1975

[et1975]

The license gives you the right, so that's not the issue. On the other hand, community involvement does not require a monorepo... anyone can make a PR. In terms of finding the bindings... how do you find any F# libs? nuget.org and npm both have search, and then there's the "awesome" list...
When the current stewardship is non-responsive, or you want to take it in a different direction, that's when you fork it... I can't see how anything else would not be counter-productive.

[mike-morr]

I search npm and nuget very rarely. Usually I will either search using Google or Github.com first. I don't want to search nuget as the descriptions usually suck. When it comes to types, I want to know how recently they were updated, how often they are being updated before I even try to install it. I could be weird though.

That being said, I was worried about it being counter productive as well if you go back and look at the Gitter messages where I proposed it. I think I actually used the words "on the fence" as to whether it would be a waste of time or not. I don't want to waste time at all.

I'm still on the fence as to it being a waste of time which is why I haven't done any work on it. Ideally it would be automated, so I could just type ts2fable @types/lodash and have ts2fable spit out a ready to go type declaration ready to use in my project. At that point we wouldn't need any repos at all, except for things that don't have a DefinitelyTyped declaration already created. However, I don't even know if that is possible. @et1975 @alfonsogarciacaro Do we think we could get to that point with the DefinitelyTyped declarations?

[Zaid-Ajaj]

Automating the bindings is itself not a very good idea. ts2fable will only give you a start on writing the bindings and then you would want to handcraft the rest yourself ,change how you want to consume the library, making it more F# idiomatic or provide helper functions with documentation etc.

[alfonsogarciacaro]

@et1975 I think this comes from a misunderstanding, I may have given the impression that I wanted to put in a mono repo the bindings from every contributor. If that's the case, I apologize because it was not my intention. I was thinking mainly in all the bindings that I originally created with ts2fable (and tweaked later) and are currently scattered through the fable-compiler.org. As commented above, 3rd party bindings shouldn't be in that repo unless original authors want to do so (forks make no sense to me).

I've mentioned some times I want to depersonalize Fable to ensure of the continuity of the project and for this I'd like to build a team where people work and take decisions together (I think we're on the right path for that). But by no means I want Fable to have a closed ecosystem where everything has go through a committee, everybody should be free to contribute to Fable in the best way they see fit.

About visibility, it's true we can use Nuget search or fable-awesome, but I still think putting all fable-compiler.org bindings in the same repo will help uniform best practices, especially at this point when we're deciding what's the best way to write the bindings.

@mizzle-mo On automation, even if we reach the point were translations with ts2fable are immediately usable (which would be awesome) I still think we'd want to have our own packages for version management. If I create a library which depends on, say, Leaflet bindings, I want the consumer to use the same bindings (not others they translated from a different .d.ts declaration or with a different version of ts2fable).

[jgrund]

@alfonsogarciacaro Any updates here? I'd like to contribute some bindings for socket.io when it's ready

[alfonsogarciacaro]

@jgrund For now I just forked fable-typed/types here as I don't have rights to push to the original repos. I was thinking to move Browser and Node bindings there and solve the issues mentioned above (remove 3rd party bindings) and then send a PR to fable-typed. But we can also discuss if it's better to keep the bindings in the fable-compiler org 👍

[jgrund]

👍 for pushing browser / node bindings and removing 3rd party ones. I think extracting them out makes sense in terms of updating fable without being pinned to a specific binding version.