Fable: nagareyama map lookup throws error incorrectly when key is a one-value D.U. encapsulated string

[tomcl]

Description

Again this is only an error for fable 3 when packed with webpack and then built with electron-builder (and note that I have switched minification off).

The packed but not built dev version works fine. And fable 2 works fine.

A map lookup throws an error (no error message). internally this is because tryFind as below returns null - this is checked in the library map find function. The key type is a string wrapped in a single-case D.U. (which the compiler should maybe get rid of, but does not.)

The wrapping D.U. type is in a different project from the code, and on the possibility that this is the same as #2285 I would next rework the code so that everything runs inside a single F# project. I use such wrapping D.U.s everywhere in my code so there might be other cases. However, it cannot be that wrapping D.U.s fail always, because I use them so much.

function Map_MapTreeModule_tryFind(comparer_mut, k_mut, m_mut) {
  MapTreeModule_tryFind: while (true) {
    const comparer = comparer_mut,
          k = k_mut,
          m = m_mut;

    if (m != null) {
      const m2 = m;
      const c = comparer.Compare(k, Map_MapTreeLeaf$2_get_Key(m2)) | 0;

      if (c === 0) {
        return Option_some(Map_MapTreeLeaf$2_get_Value(m2));
      } else if (m2 instanceof Map_MapTreeNode$2) {
        comparer_mut = comparer;
        k_mut = k;
        m_mut = c < 0 ? Map_MapTreeNode$2_get_Left(m2) : Map_MapTreeNode$2_get_Right(m2);
        continue MapTreeModule_tryFind;
      } else {
        return void 0;
      }
    } else {
      return void 0;
    }

    break;
  }
}

However I print out the value of the map, and the key used here, in the function that has this error. The key exists in the map.

                let comp = 
                    try
                        netList.[target.TargetCompId]
                    with
                    | e -> 
                        printfn "\n***************\nNetlist=%A\n\n Id=%A\n******************\n" netList target.TargetCompId
                        printfn "\n*********************************\nError in makeNetGroup: %A\n------------------------------------" e
                        netList.[target.TargetCompId]

The above code prints out the values causing the error caught by the try, then reruns the error to get an exact backtrace.

Netlist =   .... other items omitted

(ComponentId 53202b69-a682-0bb6-3582-1235e74f2377, { Id = ComponentId 53202b69-a682-0bb6-3582-1235e74f2377
  Type = MergeWires
  Label = 
  Inputs = map [(InputPortNumber 0, { SourceCompId = ComponentId 3f25de2d-971c-e9bb-8866-d4f40b9ac5d2
  OutputPort = OutputPortNumber 0
  SourceConnId = ConnectionId 9b98753f-a4ea-d83f-bc1f-9ded2e52001e });

... other items omitted
**************************************************************************
Id=ComponentId 53202b69-a682-0bb6-3582-1235e74f2377

Which proves that the lookup should correctly return the item I've shown.

Repro code

This bug is from the same code as #2285 buried deep in a set of nested collection functions and anonymous functions in my code. It will maybe take me a long time to isolate it. I'm hoping that what I've posted above might be enough.

Expected and actual results

Please provide the expected and actual results.

I expect the map lookup to return the correct map value. Instead it throws an exception with no error message other than the backtrace:

My code prints out the exception using printf "%A" e and gets the text above.

Related information

• Fable version: 3 rc0007
• Operating system win 10

[tomcl]

I've checked a simple D.U. lookup using a type wrapped string with the same types as above: this works. So it is not every such lookup failing. I'll add to this when I find out more.

[tomcl]

I assume the weird root of this backtrace is expected behaviour. The 5 calls from makeNetgroup fail with the smallest Map I can give it (3 elements). I will try to isolate the failing code.

let makeNetGroup (netList: NetList) (labelConnectedNets:Map<string,NLTarget list array>) (targets:NLTarget list) =
    let connected = 
        targets
        |> List.toArray
        |> Array.collect (fun target -> 
            let comp = 
                try
                    netList.[target.TargetCompId]
                with
                | e -> 
                    printfn "\n***************\nNetlist=%A\n\n Id=%A\n******************\n" netList target.TargetCompId
                    printfn "\n*********************************\nError in makeNetGroup: %A\n------------------------------------" e
                    netList.[target.TargetCompId]
            if comp.Type = IOLabel then labelConnectedNets.[comp.Label] else [||])
    {driverNet=targets; connectedNets=connected}

which is turned into:

function makeNetGroup(netList, labelConnectedNets, targets) {
  let connected;
  let array;
  array = Array.from(targets);
  connected = fable_library_3_0_0_nagareyama_rc_007_Array_collect(target => {
    let comp;

    try {
      comp = Map_FSharpMap_get_Item(netList, target.TargetCompId);
    } catch (e) {
      const clo1 = String_toConsole(String_printf("\n***************\nNetlist=%A\n\n Id=%A\n******************\n"));
      const clo2 = clo1(netList);
      clo2(target.TargetCompId);
      const clo1_1 = String_toConsole(String_printf("\n*********************************\nError in makeNetGroup: %A\n------------------------------------"));
      clo1_1(e);
      comp = Map_FSharpMap_get_Item(netList, target.TargetCompId);
    }

    if (equalsSafe(comp.Type, new CommonTypes_fs_ComponentType(2))) {
      return Map_FSharpMap_get_Item(labelConnectedNets, comp.Label);
    } else {
      return [];
    }
  }, array);
  return new CommonTypes_fs_NetGroup(targets, connected);
}

The print out from this showing that the code does not do what it should based on its parameters:

***************
Netlist=map [(ComponentId ccea1c9b-911d-fdd7-fd26-dc3691433d11, { Id = ComponentId ccea1c9b-911d-fdd7-fd26-dc3691433d11
  Type = Output 1
  Label = COUT
  Inputs = map [(InputPortNumber 0, { SourceCompId = ComponentId d8b79638-c225-aaea-df1e-f989ceb2e292
  OutputPort = OutputPortNumber 0
  SourceConnId = ConnectionId 44fa9d3b-8725-bd03-b2c6-00711daa615d })]
  Outputs = map [] }); (ComponentId d8b79638-c225-aaea-df1e-f989ceb2e292, { Id = ComponentId d8b79638-c225-aaea-df1e-f989ceb2e292
  Type = DFF
  Label = FF1
  Inputs = map [(InputPortNumber 0, { SourceCompId = ComponentId ebf99333-28fa-f7e2-cdf3-b2bdb3435b2e
  OutputPort = OutputPortNumber 0
  SourceConnId = ConnectionId 827e83af-06b7-2bc3-0ba4-0c4e00b3bdf6 })]
  Outputs = map [(OutputPortNumber 0, [{ TargetCompId = ComponentId ccea1c9b-911d-fdd7-fd26-dc3691433d11
  InputPort = InputPortNumber 0
  TargetConnId = ConnectionId 44fa9d3b-8725-bd03-b2c6-00711daa615d }])] }); (ComponentId ebf99333-28fa-f7e2-cdf3-b2bdb3435b2e, { Id = ComponentId ebf99333-28fa-f7e2-cdf3-b2bdb3435b2e
  Type = Input 1
  Label = X
  Inputs = map []
  Outputs = map [(OutputPortNumber 0, [{ TargetCompId = ComponentId d8b79638-c225-aaea-df1e-f989ceb2e292
  InputPort = InputPortNumber 0
  TargetConnId = ConnectionId 827e83af-06b7-2bc3-0ba4-0c4e00b3bdf6 }])] })]

 Id=ComponentId ccea1c9b-911d-fdd7-fd26-dc3691433d11
******************

renderer.js:30586 
*********************************
Error in makeNetGroup: Error
------------------------------------

[tomcl]

That makeNetGroup function, when called from top-level code with the same F# parameters, works.

function testMap() {
  let arg0, arg0_1;
  const netList = fable_library_3_0_0_nagareyama_rc_007_Map_ofSeq([[new CommonTypes_fs_ComponentId(0, "ccea1c9b-911d-fdd7-fd26-dc3691433d11"), new CommonTypes_fs_NetListComponent(new CommonTypes_fs_ComponentId(0, "ccea1c9b-911d-fdd7-fd26-dc3691433d11"), new CommonTypes_fs_ComponentType(1, 1), "COUT", fable_library_3_0_0_nagareyama_rc_007_Map_ofSeq([[new CommonTypes_fs_InputPortNumber(0, 0), (arg0 = new CommonTypes_fs_NLSource(new CommonTypes_fs_ComponentId(0, "d8b79638-c225-aaea-df1e-f989ceb2e292"), new CommonTypes_fs_OutputPortNumber(0, 0), new CommonTypes_fs_ConnectionId(0, "44fa9d3b-8725-bd03-b2c6-00711daa615d")), arg0)]], {
    Compare: compareSafe
  }), fable_library_3_0_0_nagareyama_rc_007_Map_ofSeq([], {
    Compare: compareSafe
  }))], [new CommonTypes_fs_ComponentId(0, "d8b79638-c225-aaea-df1e-f989ceb2e292"), new CommonTypes_fs_NetListComponent(new CommonTypes_fs_ComponentId(0, "d8b79638-c225-aaea-df1e-f989ceb2e292"), new CommonTypes_fs_ComponentType(19), "FF1", fable_library_3_0_0_nagareyama_rc_007_Map_ofSeq([[new CommonTypes_fs_InputPortNumber(0, 0), (arg0_1 = new CommonTypes_fs_NLSource(new CommonTypes_fs_ComponentId(0, "ebf99333-28fa-f7e2-cdf3-b2bdb3435b2e"), new CommonTypes_fs_OutputPortNumber(0, 0), new CommonTypes_fs_ConnectionId(0, "827e83af-06b7-2bc3-0ba4-0c4e00b3bdf6")), arg0_1)]], {
    Compare: compareSafe
  }), fable_library_3_0_0_nagareyama_rc_007_Map_ofSeq([[new CommonTypes_fs_OutputPortNumber(0, 0), fable_library_3_0_0_nagareyama_rc_007_List_singleton(new CommonTypes_fs_NLTarget(new CommonTypes_fs_ComponentId(0, "ccea1c9b-911d-fdd7-fd26-dc3691433d11"), new CommonTypes_fs_InputPortNumber(0, 0), new CommonTypes_fs_ConnectionId(0, "44fa9d3b-8725-bd03-b2c6-00711daa615d")))]], {
    Compare: compareSafe
  }))], [new CommonTypes_fs_ComponentId(0, "ebf99333-28fa-f7e2-cdf3-b2bdb3435b2e"), new CommonTypes_fs_NetListComponent(new CommonTypes_fs_ComponentId(0, "ebf99333-28fa-f7e2-cdf3-b2bdb3435b2e"), new CommonTypes_fs_ComponentType(0, 1), "X", fable_library_3_0_0_nagareyama_rc_007_Map_ofSeq([], {
    Compare: compareSafe
  }), fable_library_3_0_0_nagareyama_rc_007_Map_ofSeq([[new CommonTypes_fs_OutputPortNumber(0, 0), fable_library_3_0_0_nagareyama_rc_007_List_singleton(new CommonTypes_fs_NLTarget(new CommonTypes_fs_ComponentId(0, "d8b79638-c225-aaea-df1e-f989ceb2e292"), new CommonTypes_fs_InputPortNumber(0, 0), new CommonTypes_fs_ConnectionId(0, "827e83af-06b7-2bc3-0ba4-0c4e00b3bdf6")))]], {
    Compare: compareSafe
  }))]], {
    Compare: compareSafe
  });
  const target = new CommonTypes_fs_NLTarget(new CommonTypes_fs_ComponentId(0, "ccea1c9b-911d-fdd7-fd26-dc3691433d11"), new CommonTypes_fs_InputPortNumber(0, 0), new CommonTypes_fs_ConnectionId(0, ""));
  String_toConsole(String_printf("testing..."));
  const arg10 = makeNetGroup(netList, fable_library_3_0_0_nagareyama_rc_007_Map_ofSeq([], {
    Compare: comparePrimitives
  }), fable_library_3_0_0_nagareyama_rc_007_List_singleton(target));
  const clo1 = String_toConsole(String_printf("%A"));
  clo1(arg10);
  String_toConsole(String_printf("testing done."));

I wonder whether they are the same JS values, because of the types they are wrapped in.

[tomcl]

@alfonsogarciacaro

Taking this code, no change to source or build, but adding all the dependencies to the top-level renderer project, cures this problem.

So: workaround: put everything in one F# project. Bug: sometimes type references from project dependencies go wrong in code built with electron-builder. This does not (ever) happen in development code so my guess is that the type reflection code makes some assumptions about where other project type information is that breaks under the file movement done by electron-builder to create binaries. or possibly type reflection meta-information is collected during compile which breaks when JS files are rearranged. I'm not quite sure what electron-builder does - but it clearly causes problems.

The case of Json.tryParseAs obviously uses reflection.

It is a bit more surprising that Map lookup uses reflection. I'd guess it is something to do with non-erased single-case D.U. types not hashing correctly when the D.U. is reflected wrong (because it comes from another project).

I wonder whether different projects are bundled separately, in which case this might be related to #2282? The webpack setup I use bundles all of the renderer together so I don't think it is relevant.

[alfonsogarciacaro]

Interesting. Thanks a lot for the detailed information as always @tomcl! I'll try to reproduce. It's strange because Fable merges all sources so having types in different projects shouldn't have any influence, but if the webpack configuration is creating separated bundles it could indeed be related to #2282 🤔

By the way, you can use the Erase attribute for single case unions if you don't need the wrapping DU in the runtime:

```fsharp
[]
type Foo = Foo of string

let foo = Foo "foo" // This becomes just "foo" in JS.

[tomcl]

Thanks! This one I find very difficult to make a repro for, because isolating the function that goes wrong does not give me the same results. But maybe what does and does not work gives some clue. On my setup production bundles to (I think) a single bundle, certainly a single file. I guess if it behaves differently for different projects it would something in the Nagareyama js output that made that happen, since webpack is not looking for fsproj, I give it a single js entry.

Thx for [<Erase>]. I should have realised: it will be helpful in my code.

[tomcl]

Versions check

My code is currently running with

• nagareyama v 3.0.0 rc0007
• FSharp.Core 5.0 (Electron), 4.7.2 (FAKE and build)
• Dotnet 5

Should I tie down some earlier version of FSharp.core? And am I right in thinking dotnet later version makes no difference?

I'm hoping that nagareyama would detect any version incompatibility but maybe not since it is not a nuget package in the project, but instead installed as a tool.

[alfonsogarciacaro]

That should be correct, referencing FSharp.Core 5.0 is needed to use latest F# features like string interpolation.

At the end #2291 was a hashing issue, which should hopefully be fixed in latest release. It could be related to your problem too, can you please try updating Fable? dotnet tool update fable --version "3.0.0-*"

[tomcl]

3.0.0-nagareyama-rc-009

I'm afraid there is no change in this bug when using the later version. Nor (I thought I'd try) when I add [<Erase>] to all my one-case D.U.s.

[tomcl]

PS - the Json bug referenced in #2285 is probably not a bug in SimpleJson and therefore looks like the same thing as this bug. I've updated the repro branch and it stays with rc-009.

Unlike this bug it is easier to find and has a simple repro that produces the bug with very little renderer process code.

https://github.com/tomcl/issie/tree/repro-build-bug

[alfonsogarciacaro]

Hmm, I tried to run the "repro-build-bug" but not sure I'm doing it fine. Could you please list the exact commands I have to run and what should I expect? I typed npm run dev but all I got is a long log that finished with this error.

┏ Electron -------------------

  Failed to fetch extension, trying 1 more times

┗ ----------------------------
┏ Electron -------------------

  Failed to fetch extension, trying 1 more times

┗ ----------------------------
┏ Electron -------------------

  (electron) 'BrowserWindow.getDevToolsExtensions' is deprecated and will be removed. Please use 'session.getAllExtensions' instead.

┗ ----------------------------
┏ Electron -------------------

  (electron) 'BrowserWindow.addDevToolsExtension' is deprecated and will be removed. Please use 'session.loadExtension' instead.

┗ ----------------------------
┏ Electron -------------------

  (node:43892) UnhandledPromiseRejectionWarning: Error: Loading extension at /Users/alfonso/Documents/issie/node_modules/devtron failed with: The 'manifest_version' key must be present and set to 2 (without quotes). See developer.chrome.com/extensions/manifestVersion.html for details.

┗ ----------------------------
┏ Electron -------------------

  (node:43892) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
  (node:43892) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

┗ ----------------------------
┏ Electron -------------------

  Failed to fetch extension, trying 0 more times

┗ ----------------------------
┏ Electron -------------------

  An error occurred adding extension: Error: net::ERR_CERT_INVALID
      at SimpleURLLoaderWrapper.<anonymous> (electron/js2c/browser_init.js:93:6395)
      at SimpleURLLoaderWrapper.emit (events.js:223:5)
  Failed to fetch extension, trying 0 more times
  An error occurred adding extension: Error: net::ERR_CERT_INVALID
      at SimpleURLLoaderWrapper.<anonymous> (electron/js2c/browser_init.js:93:6395)
      at SimpleURLLoaderWrapper.emit (events.js:223:5)

┗ ----------------------------
^Cnpm ERR! code ELIFECYCLE
npm ERR! errno 130
npm ERR! [email protected] webpack: `electron-webpack dev`
npm ERR! Exit status 130
npm ERR! 
npm ERR! Failed at the [email protected] webpack script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/alfonso/.npm/_logs/2020-11-28T08_15_43_819Z-debug.log
npmnpm ERR!  codeERR! ELIFECYCLE
 code ELIFECYCLE
npm ERR!npm errno  130
ERR! errno 130
npm ERR! [email protected] devr: `cd src/renderer && dotnet fable watch . --run npm run webpack`
npm ERR! Exit status 130
npm ERR! 
npm ERR! Failed at the [email protected] devr script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! [email protected] dev: `cd src/main && dotnet fable watch . --run npm run devr`
npm ERR! Exit status 130
npm ERR! 
npm ERR! Failed at the [email protected] dev script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/alfonso/.npm/_logs/2020-11-28T08_15_43_847Z-debug.log

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/alfonso/.npm/_logs/2020-11-28T08_15_43_848Z-debug.log

[tomcl]

OK, so try:

dotnet paket install
npm install
npm run dev

That works with me and will resolve both paket and node package issues, I think.

Now that takes you to a dev envt running the app, but the bug does not appear in dev envt! You can see in dev tools that both the Json parses are Ok. After that, you can do

npm run dist

Run the app from dist\win-unpacked and you can see the bug.

EDIT: PS you need Ctrl-Shift-I, or menu, to toggle dev tools.

[tomcl]

Even though the repro runs fine for me, there are some errors relating to dev tools load. I've removed the extension dev tools from main.fs (and package.json) they are not needed. There are now no errors loading for me. If you take the latest commit it may therefore be more trouble-free?

https://github.com/tomcl/issie/tree/repro-build-bug

[tomcl]

Ok, so I've tested this issue, and the related and easier to debug #2285 using rc-011.

Both bugs remain unchanged.

2285 has a simple repro:

https://github.com/tomcl/issie/tree/repro-build-bug

The problem is that it seems to be not just the compiler, given it appears in bundled output but not in dev output. Still, it is clearly dependent on project structure. those two bugs go away when all code is under one F# project. AFAIK the bundler does not know anything about F# projects except what the output from nagareyama tells it - so this is nevertheless a nagareyama bug. I think.

[alfonsogarciacaro]

I tried to build again, unfortunately I cannot reproduce the issue yet. It's strange because with #2303 it worked just fine. With repro-build-bug when I run this:

dotnet paket install
npm install
npm run dev

I get the same error as above: "An error occurred adding extension". If I run npm run dist everything seems to build fine, but when I open dist/mac/issie.app I don't see anything (I can see the app menu in the top bar and the app icon in the dock but there's no window).

Anyways, I can think of the following things we could try to narrow down the problem:

• The error disappears if every file is in the same project, can you try just putting the project references within the Renderer folder? Maybe webpack/electron expect the entry js file to be on the root of the app.
• In the code handling the exception, can you the following logs? It's important to use JS.console.log instead of printfn so we get the "raw" JS objects:

JS.console.log(target.TargetCompId)
JS.console.log(Array.ofSeq netList)

[alfonsogarciacaro]

If it's happening only when building for production you can also try passing the "--define DEBUG" flag to see if it makes a difference (this is automatically set in watch mode)

[tomcl]

Thx. I will do some investigation _when I have time_.

I will certainly investigate and get to the bottom of your build issues, since my code should build happily on any system.

In addition I will bite the bullet and lower-case every single filename and .fsproj path in my build, as I normally do. It is just possible that some weirdness relating to #2277 is making my build inconsistent, though I'm not convinced. Apologies for maybe wasting everyone's time if that is the case. But, in that case @reinux suggestion to solve #2277 would be specially valuable with a very strong and informative warning message because these build issues are particularly mysterious to newbies and semi--newbies (I count myself as latter).

[tomcl]

@alfonsogarciacaro maybe don't spend any time on this till I have cleaned up all file casing in my build, but your _window does not open_ issue might be linux-specific - I do not ever test on linux directly and electron has some weird issue that makes for incompatibility between macos and win in how you initially open the window. Maybe I had this wrong for linux before, I've now made the window show on anything not windows - rather than just on macos.

https://github.com/tomcl/issie/tree/repro-build-bug

[tomcl]

Ok, i have cleaned up case issues and my repro build bug has gone away!

BUT - I was sometimes getting messages about names of library files being duplicates inside .fable. Which I now understand to be case-differentiated in directories.

I suspect this as causing many potential issues where older versions of libraries are picked up instead of newer.

I deleted all .fable files.

So - after consideration of maybe something different to do when libraries differentiated only by path names get into .fable directories this issue and #2285 could be closed.

WARNING: I was getting these library path messages on a windows system before I changed casing on any of my directories. Suggest you check .fable libraries for weird casing (I guess you do) and clean older duplicates (you don't)? Otherwise this is a big nightmare into which people can fall and the warning error message is not strong enough.

[tomcl]

@alfonsogarciacaro

[tomcl]

Just to summarise. My problems #2285 #2293 are due to my capitalisation of directory or file names inconsistent between on disk and in json files.

However, this is because Nagareyama behaves differently from fable 2 in this respect (because the same code worked fin with fable 2).

I'm still not exactly sure which case sensitive behaviour here is the problem. One issue that I thought previously was not a problem, but maybe is a problem, is that my .fable files had multiple differently capitalised versions of libraries in them after the change to fable 3. Although this caused a warning, it was easily ignorable. In fact I posted it here in one of these issues... I thought it was referring to different capitalisation of library functions - and it did not make much sense - it was different capitalisation of library file paths.

[tomcl]

@alfonsogarciacaro

So here I think is the bug.

If I delete and reclone my repo, then compile for dist, I get two copies of library files in .fable, with a warning:

    WARNING in ./src/Renderer/.fable/fable-library.3.0.0-nagareyama-rc-011/lib/long.js
    There are multiple modules with names that only differ in casing.
    This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
    Use equal casing. Compare these module identifiers:
    * C:\github\issie\node_modules\babel-loader\lib\index.js??ref--4!C:\github\issie\src\Renderer\.fable\fable-library.3.0.0-nagareyama-rc-011\lib\long.js
        Used by 48 module(s), i. e.
        C:\github\issie\node_modules\babel-loader\lib\index.js??ref--4!C:\github\issie\src\Renderer\.fable\fable-library.3.0.0-nagareyama-rc-011\Long.js
    * C:\github\issie\node_modules\babel-loader\lib\index.js??ref--4!C:\github\issie\src\renderer\.fable\fable-library.3.0.0-nagareyama-rc-011\lib\long.js
        Used by 48 module(s), i. e.
        C:\github\issie\node_modules\babel-loader\lib\index.js??ref--4!C:\github\issie\src\renderer\.fable\fable-library.3.0.0-nagareyama-rc-011\Long.js
     @ ./src/Renderer/.fable/fable-library.3.0.0-nagareyama-rc-011/lib/long.js      
     @ ./src/Renderer/.fable/fable-library.3.0.0-nagareyama-rc-011/Long.js
     @ ./src/Renderer/UI/PopupView.fs.js
     @ ./src/Renderer/Renderer.fs.js
     @ multi ./src/Renderer/Renderer.fs.js ./src/Renderer/scss/main.scss ./static/index.html

The actual path is ./src/Renderer/*. My .fsproj files and my .sln file all use consistent capitalisation Renderer.

To do the build, if I invoke:

"compile": "dotnet fable src/main && dotnet fable src/renderer" // fails, but not obviously, results in run-time bug

"compile": "dotnet fable src/Main && dotnet fable src/Renderer", // it is OK!

So that has nailed this bug, and #2285.

[alfonsogarciacaro]

Sorry @tomcl, I was so excited that we finally managed to fix this bug that I just went ahead and published Fable 3 "official" with the fix. I've used the helper from the SO link provided by @reinux, this should ensure that we get proper casing of the project directory no matter how the user types it. I feel a bit silly now, because I remember now we already talked about the case difference between src/renderer and src/Renderer in one of our discussions, so the solution was in front of us all the time but I couldn't see it. Luckily @reinux came to the rescue!

I also want to say thanks to you @tomcl, @inosik, @reinux et al for all the time and effort you've spent testing Fable 3 release candidates. I'm sure you've saved countless hours for many users that happily won't have to deal with obscure bugs like this. Of course, if you find anything else in the _stablish_ releases please report it 😄

Please keep building great apps with Fable!