Fable: Local transitive dependency error: Two type definitions named 'PromiseSeq`1' occur in Fable.PowerPack.fsproj in two parts of this assembly

[Zaid-Ajaj]

I am writing a library and a consumer app of that library following this structure/dependency graph:

Library.fsproj depends on Fable.PowerPack for it's internal functionality, Aside from that I want to use Fable.PowerPack inside ConsumerApp.fsproj for other purposes so I need it there too.

Becuase I am working simultaneously on both projects ConsumerApp and Library I have all local dependencies installed, i.e. there is node_modules directory in the same directory as ConsumerApp.fsproj and another node_modules in the same directory as Library.fsproj

Both projects open with different instances of vs-code, no errors present.

When I build ConsumerApp, files of Fable.PowerPack are read twice (once from dependencies of Library.fsproj and another time from dependencies of ConsumerApp) resulting in the error you see in the title.

Notice this is all still on my machine, so it's different than the discussion of the distribution of the transitive deps. I will worry about that later.

This issue is also different than Error: An implementation of file has already been given because here it is complaining about duplicate type definitions instead of duplicate file names.

Please advice and let me know if a repro sample is needed

[alfonsogarciacaro]

Can't you have a common node_modules folder for both projects (like samples in Fable repo)? I guess this should solve the issue. Anyways, this problem should be fixed when you moving to Paket... unless you have a different paket.dependencies file for each project, which is not a common practice.

[johlrich]

If you did want to keep each project separate, you could npm link your library into your consumer app. If you go down this route, webpack needs to be configured to not resolve symlinks:
In webpack.config.js:

   resolve: {
     symlinks: false
   },

[Zaid-Ajaj]

@johlrich this is amazing! it just worked ❤️ thanks a lot!

For peaple bumping into this, I also read the article npm link: developing your own npm modules without tears which was very helpful

@alfonsogarciacaro Sharing dependencies isn't favorable becuase when I publish the library to npm it will pick up the consumer deps along with it. By the way, I was making all samples seperate, so they no longer share deps across other samples to make it easier for people to understand (1 directory = 1 full sample)

[alfonsogarciacaro]

Not sure if I understand the problem when publishing the packages. A trick we did with Elmish was to set different paths for development and publishing. But again, this will probably be not necessary any more when we move to Paket.

About the samples, I didn't notice you were installing the dependencies separately for each one... that's fine, I guess. We had a similar discussion in the past. I just find a bit annoying having to install almost the same dependencies over an over again for each sample and all the disk space this takes (1 sample around 100MB, 10 samples around 1GB). To build all samples Fable repo will be heavier than Visual Studio 😅

[Zaid-Ajaj]

@alfonsogarciacaro Say you write a js module and you have other modules inside dependencies in your package.json and you publish your module. Then, to my understanding, when a consumer app npm installs the library, that all the dependencies of that library are downloaded too. So if I share both consumer app deps with library code deps and publish my library, wouldn't these consumer app deps also get downloaded when someone npm install my library?

About the samples, I made the assumption that someone almost never wants to build all samples at once. Samples are there to see how one thing is done (use canvas, import external libs, node app etc.) or that something is possible and if someone wants to browse throught all the samples, he can use the docs site where they are all live. I personally find a lot easier this way. You would only want to build all samples when generating a static docs site but I think we will provide and put a build to each sample manually one at a time

If this approach makes you unhappy, let me know and I will roll-back, it is no problem :smile:

[Pauan]

FWIW, I think not sharing dependencies for the samples is the right way to go.

[MangelMaxime]

I like not sharing dependencies too as the user can pick a sample and it's already self contain :)

@Zaid-Ajaj We will be building and the samples at once each time we update the fable doc site. (will see if it's really too long or not).

Also, it's a fully automated process or a one command process it's probably not a problem. Like build.sh PublishDocSite and it's compile everything need and auto push the website to right repo.

[alfonsogarciacaro]

@Zaid-Ajaj I don't have a clear picture yet of the structure you're using so I don't fully understand the problem. But in any case, let's wait until the Paket integration because dependencies will be better managed then and maybe the problem just disappears.

About the samples, I see the point of having each sample independent of each other, but still don't like very much having so many node_modules folders scattered through the repo. This will be aggravated after Paket integration because to follow suit we'll have to duplicate the packages folder for every sample (and FSharp.Core alone weights around 50 MB).

In the JS world it's usually recommended to install dependencies separately for each single project. But in F#/.NET world it's normal to have multiple projects grouped in a "solution" sharing dependencies. When using Ionide, I don't use .sln files but the concept of a solution in my mind translates to a workspace (=directory). This will probably be easier to see after Paket integration, a moment when it may be also a good idea to move the samples to a different repo so the solution structure is clearer. If we really want the samples to be self-contained (something not so important since we have templates, as that's what people should use when starting a project from scratch) we would have to put each one in its own repo, but that makes maintenance more difficult (at least for me).

You would only want to build all samples when generating a static docs site

That's precisely the use case I was thinking of :wink: In the past building, all the samples was a pain point as it was slow and any single error forced repeating the whole process again (that's basically the reason I haven't updated the samples for a long time). But now Fable can compile several projects in parallel, and it'd be nice to take advantage of this feature.

[Zaid-Ajaj]

@alfonsogarciacaro I totally understand your point. The thing is that I was talking from a user's point of view and you are talking from a maintenance point of view.

When I started learning I didn't touch the samples becuase it would be too many things to install on my machine just to see something working locally and I had to start from scratch and copy paste code. Where I usually I learn by taking what people wrote (clone a repo, preferrably) and tweek it my own way to see what things change etc. So having self-contained samples is very pleasant

Maintenance costs however should also be considered, as we are still pretty much short on contributers.

An ideal course of action is to make another org for the samples (e.g. fable-samples), with a repo for each samples that has a live preview on it's gh-pages branch. Much like what we were doing with elmish. I can go ahead and start with this right away but help from @fable-compiler/documentation will be needed as well

What do you think?