Fable doesn't work when using links for Nuget cache

[milbrandt]

Description

As drive C: is pretty full I relocated the directory %USERPROFILE%\.nuget to another drive and linked with mklink /J .nuget F:\.nuget.

With this link, our Fable project is failing to compile, see console output below. (Without the link, it compiles fine and is working.)

To check if NuGet is the issue, I tried in Visual Studio to compile one of the C# Projects using NuGet and that works fine.

Console Output

Fable (1.3.17) daemon started on port 61225
CWD: F:\Repos\Company.EcoPage\source\Client
cmd /C node "F:\Repos\Company.EcoPage\node_modules\webpack\bin\webpack.js" -p
Bundling for production...
Parsing ./Client/Client.fsproj...
fable: Compiled Client.fsproj
fable: Compiled Client.fs
ERROR: F:/.nuget/packages/fable.elmish/1.0.3/fable/program.fs doesn't belong to any of loaded projects [[F:/Repos/Company.EcoPage/source/Client/Client.fsproj, F:/Repos/Company.EcoPage/source/Client/Client.fsproj]]
   at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1379.Invoke(String message)
   at [email protected](Tuple\`2 _arg1)
ERROR: F:/.nuget/packages/fulma/1.0.0-beta-024/fable/Common.fs doesn't belong to any of loaded projects [[F:/Repos/Company.EcoPage/source/Client/Client.fsproj, F:/Repos/Company.EcoPage/source/Client/Client.fsproj]]
   at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1379.Invoke(String message)
   at [email protected](Tuple\`2 _arg1)
ERROR: F:/.nuget/packages/fable.elmish/1.0.3/fable/cmd.fs doesn't belong to any of loaded projects [[F:/Repos/Company.EcoPage/source/Client/Client.fsproj, F:/Repos/Company.EcoPage/source/Client/Client.fsproj]]
   at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1379.Invoke(String message)
   at [email protected](Tuple\`2 _arg1)
ERROR: F:/.nuget/packages/fulma/1.0.0-beta-024/fable/Elements/Button.fs doesn't belong to any of loaded projects [[F:/Repos/Company.EcoPage/source/Client/Client.fsproj, F:/Repos/Company.EcoPage/source/Client/Client.fsproj]]

 [43] F:/.nuget/packages/fulma/1.0.0-beta-024/fable/Layouts/Tile.fs 420 bytes {0} [built] [failed] [1 error]
 [66] F:/.nuget/packages/fulma/1.0.0-beta-024/fable/Elements/Tag.fs 420 bytes {0} [built] [failed] [1 error]
 [84] F:/.nuget/packages/fulma/1.0.0-beta-024/fable/Elements/Heading.fs 424 bytes {0} [built] [failed] [1 error]
 [85] F:/.nuget/packages/fulma/1.0.0-beta-024/fable/Elements/Content.fs 424 bytes {0} [built] [failed] [1 error]
 [86] F:/.nuget/packages/fulma/1.0.0-beta-024/fable/Layouts/Container.fs 425 bytes {0} [built] [failed] [1 error]

ERROR in F:/.nuget/packages/fable.elmish.react/1.0.3/fable/react.fs
Module build failed: Error: F:/.nuget/packages/fable.elmish.react/1.0.3/fable/react.fs doesn't belong to any of loaded projects [[F:/Repos/Company.EcoPage/source/Client/Client.fsproj, F:/Repos/Company.EcoPage/source/Client/Client.fsproj]]
    at Loader.fableUtils.client.send.then.r (F:\Repos\Company.EcoPage\node_modules\fable-loader\index.js:67:22)
    at <anonymous>
 @ ./Client.fs 28:0-108 138:18-25
 @ ./Client.fsproj
 @ multi babel-polyfill whatwg-fetch ./Client.fsproj

ERROR in F:/.nuget/packages/fable.elmish/1.0.3/fable/cmd.fs
Module build failed: Error: F:/.nuget/packages/fable.elmish/1.0.3/fable/cmd.fs doesn't belong to any of loaded projects [[F:/Repos/Company.EcoPage/source/Client/Client.fsproj, F:/Repos/Company.EcoPage/source/Client/Client.fsproj]]
    at Loader.fableUtils.client.send.then.r (F:\Repos\Company.EcoPage\node_modules\fable-loader\index.js:67:22)

Expected: Compiles as if .nuget would be located in %USERPROFILE% directly and not as a link.

EDIT: Solution below

[alfonsogarciacaro]

Hmm, we're using dotnet SDK to resolve references so I don't know if we can do anything here. Is this maybe an issue of MSBuild or Dotnet.ProjInfo that cannot resolve file links? (cc @enricosada) Do normal .NET Core projects work?

Also, could you please run Fable with --verbose argument so we can see the list of resolved paths when parsing the .fsproj?

[milbrandt]

Attached you'll find the output of dotnet fable webpack --verbose -- -p
build.log

For testing I just create a new dotnet project dotnet new console. This compiled and printed Hello World! as expected.

Standard .NET Solutions using NuGet compile fine in Visual Studio 2015.

[alfonsogarciacaro]

Thanks for the log @milbrandt 👍 So as expected the list of resolved files when parsing the .fsproj point to the .nuget cache in C: (like C:/Users/MYUSER/.nuget/packages/fable.powerpack/1.5.1/fable/src/Promise.fs). However, I guess that when the system is going to read the file, the OS resolves the link and redirects it to the actual path and this is what's included in the request to Fable compiler from the Webpack loader. However, because the link and the actual path are different, the search in the project files dictionary fails.

This is the tricky, I'm not sure how to solve it. Is there an easy way from .NET to ask the OS if a path is a symbolic link?

[alfonsogarciacaro]

Unfortunately, this doesn't seem to be implemented yet 😕

[alfonsogarciacaro]

As a work around, maybe we could add a Fable CLI argument so you can set the .nuget cache path manually.

[matthid]

@alfonsogarciacaro another option would be to disable the symlink resolution in node. The following seems to work for me:

• in one shell use dotnet fable start

• edit webpack.config.js and add symlink: false to the module.exports.resolve object

  module.exports = {
    resolve: {
        symlinks: false,
        modules: [resolve("../../node_modules/")]
    },

  See https://github.com/webpack/enhanced-resolve/blob/bc891e94acd386b0b57c918c4046c6d2990e99c5/README.md#passing-options-from-webpack

• in another shell use node --preserve-symlinks "C:\temp\TEST\node_modules\webpack\bin\webpack.js" -p

It seems further testing reveals that --preserve-symlinks is apparently not even required. So editing webpack.config.js is the only thing we need to do?

[alfonsogarciacaro]

Wow, nice one! Thanks a lot for checking this @matthid! @milbrandt Could you please add resolve.symlink: false to your webpack.config and see if this fixes the issue?

[milbrandt]

@alfonsogarciacaro The solution with symlinks: false is working (beware of your typo). So I can now move the NuGet Cache to another drive to gain free space on drive C. Thanks to @matthid.

[alfonsogarciacaro]

Thanks a lot for confirming @milbrandt. Let's accept this as the solution and close the issue for now, but please reopen it if you still experience issues. I've edited the title and the description trying to make it easier for other people to find the solution if they face the same problem.

[Nhowka]

Is there situations where symlinks: false break normal stuff? If not, that could be the new default. I'll copy that idea of having the nuget cache on a secondary drive. 😗

[milbrandt]

@Nhowka I committed the changes to our company repo and for colleagues who didn't moved their Nuget cache everything still works.

[alfonsogarciacaro]

@Nhowka We cannot control Webpack defaults, although we could add the option here: https://github.com/fable-compiler/webpack-config-template