Fable 2.1: back to npm, back home

[alfonsogarciacaro]

In the beginning Fable was distributed through npm, and all was good.

Then Enrico, the prophet, came and showed us the promise land of netcore. We followed him but when we reached the gates of paradise we heard a voice: "If you want to enter, you must forget npm and embrace Nuget, you must become a dotnet cli tool".

There was fear, everybody could remember scary stories of Nuget from the old days. Nobody dared to move, but then one man stepped forward, his name was forki. "Fear not", he said, "for I will make Paket handle dotnet cli tools".

There was a big party that night, Paket kept the cli tools and the other Nuget packages under a tight lock so they would make no harm. The gates of paradise could be crossed now.

Soon however, some people raised their voice: "why do I have to type three commands? What is this, dotnet, fable, webpack? My head hurts". But the voices were silenced: "Don't try to understand such arcana", they said, "Maxime, the French magician, will unveil the mysteries for us and bring the Webpack configs and Fake scripts".

So people were happy and felt SAFE. But then the voice of the big M came down from the sky again: "You, why are you using dotnet cli tools?". "Because you told us to do so", the fablers replied. "How you dare, you fools! Dotnet cli tools were a mischief from the devil and I shall provide support no more".

The fablers were confused, they were trying to build bridges between two worlds, but the currents were constantly changing. At the moment of biggest despair, there was an open hand from the other side: "Come back, my prodigal son. Do you want to be a cli tool? No ProbleM! You can be whatever you want to be if you come with me. You can put any files you want in your packages. Dotnet assemblies? It's ok, I won't judge you! The only tribute you need to pay is just a little json."

And fablers saw the light: if we need to call webpack anyways, why not just type "webpack"? Why not put the dotnet assembly in an npm package and let fable-loader spawn it a subprocess? Why not communicate with it just through stdin? Then users won't have to worry, just install the fable loader and be done.

Suddenly, the sky cleared and a ray of light fell onto the fablers. The netcore trees hadn't let them see the forest of the user experience so far. But now the answer was clear, they wouldn't wait for big M promises any longer. They would go back to npm, back home.

[MangelMaxime]

Just to confirm we are moving only dotnet-fable to npm not the libraries like Fulma, Elmish, etc. ?

Also, if dotnet-fable goes to npm perhaps it a good time to release fable-core as an npm package as some people needs it to be distributed like that. So dotnet-fable will have to required fable-core as dependencies in the package.json.

[inosik]

Typos here.

[inosik]

What about this?

use writer = new JsonTextWriter (writer, CloseOutput=false)

Looks like the JsonTextWriter returns a buffer back to a pool on Close, which is called by Dispose.

[alfonsogarciacaro]

Good point! Let's do that, thank you!

[alfonsogarciacaro]

@MangelMaxime Everything was totally clear in the first comment, how you didn't understand? 😸

Jokes aside, yes, this is only about moving dotnet-fable (Fable CLI, Fable dotnet binaries or however you want to call it) to npm (actually the official name of the package is fable-compiler-dotnet as fable-compiler was already used to publish the new pure-JS Fable CLI by @ncave). The experience with Fable 0.7 showed that managing F# libraries with npm caused problems with editors, so we'll keep them in Nuget as it's now.

In fact users won't even need to care about fable-compiler-dotnet, because this is now a dependency of fable-loader and fable-splitter. The only thing that changes is you call webpack directly (e.g. yarn webpack-dev-server). BTW, new beta versions have already been published, you can try them out by installing fable-loader@next and fable-splitter@next. fable-splitter has also been updated to make it easier to run node apps (now you can do something like yarn fable-splitter src/ --run).

About fable-core, this has been discussed somewhere else, but we won't release it as a standalone npm package. This is because it's not designed to have a consistent public API (sometimes there are breaking changes to fix errors in the compiler), only to support injections from the Replacements module. It was very difficult to keep in sync fable-core and fable-compiler dependencies in Fable 0.7, and we don't want to go through that again. If someone needs the JS files, they can build and take them from Fable repo. Also, anyone is free to take the JS files and publish an npm package, but they should maintain it by themselves.

[inosik]

Can we start Fable with a debugger attached with this setup?

[alfonsogarciacaro]

@inosik I already added a cli.path option to fable-loader so you can specify a path to use a local build. Maybe we should also add a cli.args option so you can specify the full args (e.g. ["run", "-p", "../my/local/source"]) and build in debug mode so you can attach a debugger later, what do you think?

[MangelMaxime]

@alfonsogarciacaro Seems good too me and looks like the right decision for managing the tool version and making integration with webpack even better :)

Just wanted to make sure :)

[inosik]

@alfonsogarciacaro Yeah, I've already seen this setting, but honestly I didn't expect it to be the path to the project file instead of pointing to an assembly. Adding an args option sounds good, but I think we'd need to add some "wait for debugger" flag, to be able to actually attach a debugger to the newly created process. Or we add a --debug flag and use Debugger.Launch or Debugger.Break. I never used these though, even on the full .NET Framework. And I'm not sure how good they work on .NET Core and non-Windows platforms.

[alfonsogarciacaro]

Fable 2.1 has been released 😸