• Could you go into some more detail about what this process involving paket is supposed to look like?
• If the development and consumption paths are different can't this be handled by some sort of fable pack to create the desired nupkg structure?
• When you say sources for the project I'm assuming you mean the .js files, do you mean they should be found in content or contentFiles?
• Could this be handled by a .targets file so that all paket would need to do is add the targets to the fsproj?

I worry about putting additional stuff into the /obj/ dir as detritus in it has led to weird tooling issues for me in the past, but maybe it won't matter in this case. If you're talking about creating the same resource, props, and targets files that msbuild uses as manifest resources for the new msbuild15 fsproj, we're still relying on nuget to do that and I'm not sure if we could use the same mechanism for fable or if this would have to wait until we implement our own way to do this that doesn't involve nuget at all.

But overall I'm still really unclear on what specifically you want us to do.

If I understand correctly we would scan for fsproj files in all referenced packages and build a targets file that imports all of these fsproj. We also would need to ensure some kind of order. Is that correct? Anything else to do?

Hi again! Sorry, after considering this further and checking with other stakeholders (I always wanted to say that), we're going to explore distribution of .dll F# source files. This makes it very easy for Paket and IDEs because then Fable packages are indistinguishable from others, and then Fable can pick the F# sources for the compilation.

The only thing that Fable would need is the full list of Fable dependencies in compilation order. For example, if the user had Fable.Elmisht.React in paket.dependencies, it'd be very nice if Paket could somehow provide the following:

Fable.PowerPack
Fable.React
Fable.Elmish
Fable.Elmish.React

Fable already contains an algorithm to resolve dependency graphs, so it's also ok to have something like this:

Fable.Elmish.React
    Fable.React
    Fable.Elmish
Fable.React
Fable.Elmish
    Fable.PowerPack
Fable.PowerPack

For now it should be fine to just assume packages prefixed with Fable. are Fable packages, we can think of something else later.

Crazy thinking:

What about adding a frontend to npm into paket to stay in npm ecosystem as @forki is suggesting time and time again?

So having something like fablegroup where you can add npm packages. Resolving and installing via npm and adding some fable specific logic on top?

Disclaimer again: I have not used fable just jet. So I have no idea how possible this is technically...

npm is going to be needed anyways for tooling like Webpack, Babel, and other JS libraries, so even if we push Fable libs to Nuget, it could still be a good idea for Paket to interact with npm for people who prefer to use only one package manager.

@alfonsogarciacaro for MSBuild 15 projects we already put a *.fsproj.references file into the obj folder (on restore). This file contains a list of all deps and has following structure:

PackageName,Version,[Transitive|Direct]

would this be enough?

True, I had seen that file before but it didn't cross my mind that it could be used for this purpose.

I just gave it a quick try: I created a project with a paket.references file including Fable.Compiler. However, after running paket install and dotnet restore, I cannot find in the obj/myproj.fsproj.references file the dependencies of Fable.Compiler (like Fable.Core or Newtonsoft.Json), which means it's not useful to solve the full dependency graph. Or am I missing something?

can you upload your test project for me to repro?

Ups, it seems I did mess up things: when building the repro repo (you see what I did here, right?) I did see all the dependencies, so that should be fine. Now the only issue would be the order of the dependencies. If I only include dotnet-fable in paket.references I correctly get the dependencies in (inverse) compilation order: dotnet-fable < Fable.Compiler < Fable.Core. However, if I list all the dependencies in paket.references, they will appear exactly in the same order in the *.fsproj.references, so this may be a problem if the user lists them in arbitrary order:

FSharp.Core
dotnet-fable
Fable.Core
Fable.Compiler

Repro repo: https://github.com/alfonsogarciacaro/TestProject

ok fixed in latest paket 5 alpha.

they are now ordered so that a package down in the list only references packages above itself (similar to what we do with fs files in a fsproj).

Super-fast, thank you! I'll try to have a prototype asap 👍 I will also put Fable.Core JS files in the Nuget package to prevent the Fable.Core / fable-core split.

BTW, not directly related but what would it take for Paket to manage also DotNetCliToolReferences? That would be the last piece to manage all Fable libs and tools (at least on .NET side).

I'm ccing @enricosada just because I like to bother him constantly ;)