Reference Fable libraries

[MangelMaxime]

@ncave @alfonsogarciacaro

Are we able to support solution project ? Or multi files project in current state ?

If not, what is missing ? And can I help ?

[ncave]

@MangelMaxime Not at the moment, more of FCS needs to be ported for that to work (Incremental builder etc.). Technically several files can be joined together and compiled as one, but that's going to get slow at some point. But before that, what is your platform file system for supporting projects / multiple files, is it browser or nodejs, or perhaps GitHub?

[MangelMaxime]

@ncave I was having the idea of using the Browser.

My idea, was to explore providing a DSL or small library to the user and let him play with it and have "immediate" feedback.

[ncave]

@MangelMaxime Just to get a better understanding of what you are trying to do, do you mind explaining a bit more in detail how you are envisioning the repl to work with multiple files in a browser context? Would there be a server back-end of some kind, or local file storage?

[MangelMaxime]

@ncave This the great question :) and one of the raison I started this discussion.

If we were on the server side, we could simply use the file system to reference the different file like we do for the F# compiler on .Net etc.

It's important to note, that I never really look at the FCS code only when working the build system because I was having errors due to the change for netcore2.

One of my idea is something like that.

First, let's take the assumption we use .fsx project just because their looks simpler IMO. (I can be wrong)

• Start a service (let's call it project service)
• Feed him with all the files with a path and the associated content
• Run a first compilation
• Now when we modify a file we send the file path and the new content.
• This is update in the file in the project service and trigger another compilation.

In pseudo code, this would looks like:

{ cmd: "start_project",
  name: "repl.project" }

{ cmd: "add_file",
  name: "lib1.fsx"
  content: "....." }

{ cmd: "add_file",
  name: "App.fsx"
  content: "....." }

{ cmd: "first_build" } -> send the result one way or another

{ cmd: "modify_file",
  name: "App.fsx",
  content: "new content of the file..." }

My idea, behind this service is to make it available for the editor because, we could use it to provide some kind of folder view, and more importantly retrieve the file content. And also, make the FCS filesystem's calls pass by this service.

Nothing prevent us, later to allow the service to save it's state into the localStorage for example to restore on new tab etc.

In theory, this is something doable at least for the editor part, after I don't know how the FCS works.

[ncave]

@MangelMaxime In principle this is doable, but will need more work on FCS side to include the IncrementalBuilder and whatever additional dependencies it has. As for errors in netcore2, yes, those have not been resolved yet, but for now you can switch back to the older binaries (just have them checked in and skip the export part), you just need to check-in a more recent FSharp.Core.dll (net45 flavor).

[MangelMaxime]

Ah but now, but only have two logs with missings dlls when using netcore 2.0 so it's fine :)

Also, the export part is already optional by default in the new build system. I need to do the documentation of it.

And is it possible to not use the IncrementalBuilder for multiple files project ? Like temporary doing a full compile from scratch ? I know it's can be slow for big project probably but just for experimentation should be enough perhaps.

[ncave]

@MangelMaxime The missing dlls are not what I'm referring to as errors, there is a javascript error when parsing some files (e.g. sudoku sample etc.) when using netcore2.0 binaries that needs to be addressed before it can be declared fully functional. The incremental builder and the project system in FCS seem to be somewhat interlinked (although I'm not a FCS expert or maintainer so my understanding is limited), so I'm not sure how much we can save there by only doing the project/file system in FCS.

[MangelMaxime]

@ncave Ah ok, I wonly tested on really simple application good to know. I will first work on the documentation and if I can try something for the project/file system of FCS or do we have others things to do first ?

[ncave]

@MangelMaxime I don't know what the repl project priorities are, perhaps @alfonsogarciacaro can shed some light.

[alfonsogarciacaro]

The REPL will be what you want it to be :wink:

About solution files, that's probably too much atm. It'd be nice to have some sort of project, with files maybe saved in the browser local storage. I know FCS offers a virtual file system but I'm not sure if this part compiles to JS. Also @ncave, FCS now can get the AST of a single file with ParseAndCheckFileInProject, do you think this changes something?

Anyway, I personally think the feature with the biggest impact would be to allow referencing libraries (like Elmish, etc), ideally directly from, say, Github, but I guess it'd be fine if there's already a library of libraries to choose from. In that case, we could avoid performance problems by precompiling the libraries and bring back the .fablemap file that was used to convert references to files in libraries to JS imports when Fable libraries were distributed in precompiled form in Fable 0.7.

[MangelMaxime]

The solution project idea was to bring library support as we need the source files for Fable no?

[alfonsogarciacaro]

If we bring back the .fablemap file we could use just a .dll (plus compiled JS files) no need for the F# source file. I don't want to do this for standard Fable, as we agreed we won't distribute libraries as compiled JS files, but it may make sense for the REPL as compiling many files is much more expensive.

[mike-morr]

I would love to see something like this for Fable. This is really well done in my opinion.

https://stackblitz.com/edit/angular-7ycw9p?file=app%2Fapp.component.html

[MangelMaxime]

Something I didn't think about is that, we also can run Fable or FCS over NodeJS too. We don't only have the browser to support.

Perhaps, it can be easier to support NodeJS to test the FCS. And then use a polyfill or additional layer to support the browser.

[alfonsogarciacaro]

I don't think there'll be much difference in using NodeJS, all the code after compiling FCS/Fable to JS is browser-compatible. The only difference is how to read files.

[MangelMaxime]

Do you mean FCS/Fable already support reading the files from the filesystem when targetting Node JS ?

[ncave]

@MangelMaxime No, right now there is nothing file-system specific about FCS compiled to JS, it's just a F# to AST parser/typechecker. You can definitely use the nodejs file system to load file contents if you want to, that's what the repl testapp does, for example.

That's why I keep asking what use cases we want to support first:

• Is it NodeJS compiler CLI tooling, possibly even generating binaries.
• Is it some other type of NodeJS editor integration in a Electron shell.
• or is it Browser-based only, with or without a back-end file system. (but IMO those are all very, very different).

One possible example of a browser-based multi-file editor was something like this: (unfortunately I don't have a link anymore as I forgot what the project was called, but it has not been maintained since last year I think):

• A multi-file online editor project with GitHub backend, so on the left you have a treeview of your github project files, and an editor on the right, and you can switch between files, and you have file system backed by git.

@MangelMaxime tl;dr It would help if we have a list of features we envision for the new repl, so we can prioritize properly.

[alfonsogarciacaro]

This would be my list of priorities (of course it's not mandatory, we should decide that together):

1) Browser based, we already have a Fable CLI tool, and the most interesting scenario for REPL is users can try it out in the browser with zero installation and no backend (so in the future anybody can easily embed the REPL in their websites). 2) Store and share snippets, for that we do need some simple backend with storage. I can take care of that :) 3) More than multiple files, it'd be very nice if there was a set of common libraries the user can reference from the snippet. For that we need to either make the JS-compiled FCS accept multiple files or precompile the libraries (but then I have to solve the inline issue https://github.com/fable-compiler/Fable/issues/1257)

[MangelMaxime]

Here is my vision of the REPL.

The next version of it, should be more of less what we have on the PR #8 with all the errors fixed and missing features that I listed.

Missing features and known bug:

• Intellisense is broken: https://github.com/fable-compiler/fable-repl/pull/8#issuecomment-347842522
• Support code sharing via queryParams like the "old" REPL do
• Improve performance I get some micro-freeze or add message when the FCS is working to alert the user
• Add basic samples like the Mario sample etc.
• Clean up the code to make contribution easier

---

1. Support importing libraries. We should already be able to support pure bindings because Fable.Import.Browser is a binding for example.
2. Support common libraries like Elmish which is somekind one of our best showcase
3. Allow users to share projects, thanks to a simple backend
4. Only then support multiple files solution.

So yes for me the priority is to support the REPL in the browser before the NodeJS case.

[alfonsogarciacaro]

Now that the REPL is online, besides some performance improvements the next step is probably to enable some libraries for loading. I'm thinking Fable.React, Elmish, Recharts, probably something for canvas (Pixi?)...

Ideally the user would open a menu to select the libraries to load, then libraries would be loaded just once, and recompilations only affect the test file. @ncave is this possible? How does the InteractiveChecker work? Can we compile multiple files (for the libraries) and then later only a single file?

[ncave]

@alfonsogarciacaro Adding support for multiple files requires taking in the FCS IncrementalBuilder (currenly just a stub), which manages the incremental build graph for the build of a single F# project. It's definitely possible, but all the parts that are not applicable have to be cut out. Also, the order of importing the libraries will have to be managed somehow (or fixed, and enabled through checkboxes perhaps).

[MangelMaxime]

To fix the order of the libraries, we can imagine a simple tree item with drag & drop support.

[ncave]

@alfonsogarciacaro Perhaps it will be possible to extract just a simplified flow from the IncrementalBuilder to satisfy the fixed use case above (precompiled libraries + something), once we get a good understanding of how the incremental builder works.

[alfonsogarciacaro]

Thanks for the info @ncave. Sorry, I should have been more clear about what I meant with "libraries" for the REPL:

• Libraries will be source files (not .dlls) as in CLI Fable compilation.

• Libraries cannot be precompiled, they need to be compiled on-the-fly (when selected) so Fable can load into memory inline expressions, etc.

• I guess we could just compose a big file out of all the sources (similar to what CLI Fable does by creating a single project with all sources) but that would make compilations very slow. That's why it would be ideal to compile everything once and later compile only the user file.

• For now I was just thinking of having a small list of available libraries, so we can predefine the order and dependencies by ourselves. For example:

• [ ] Fable.React

• [ ] Fable.Elmish

• [ ] Fable.Recharts

In any case, I agree it'd be perfect to give it a try with the IncrementalBuilder and see what problems we need to solve. I'm sure forki, Vasily or Don will help us if needed.

[alfonsogarciacaro]

@ncave For Fable 2.0 I'm considering resolving inline functions with Fable AST instead of FCS'. This should allow serialization of the AST so we can "precompile" the libraries and keep the interactive checker as it's now.

I'll let you know of any progress on this regard :+1:

[ncave]

I'm not sure how that would work, but I hope you do :=) Are precompiled libraries only going to expose inline functions?

[alfonsogarciacaro]

I'm not sure now, but that's what I was thinking at the moment. Though being able to easily (de)serialize the whole Fable AST may open interesting scenarios :)

[alfonsogarciacaro]

I'm not sure now, but that's what I was thinking at the moment. Though being able to easily (de)serialize the whole Fable AST may open interesting scenarios :)