Fable: inline modifier messes up webpack re-compilation (probably expected behavior)

Created on 19 Aug 2018  路  5Comments  路  Source: fable-compiler/Fable

Description

Fable in-lines extension methods (maybe static class methods?) and causes webpack to not pick up source changes and re-compile.

Repro code

ExtensionExample.zip

Expected and actual results

Download the sample, open a command prompt or powershell prompt at ExtensionExample\Main, run yarn to install dependencies, run ./start (a batch file) to start the Fable daemon with webpack watching.

If you make changes to any of the files (Main.fs, Util.fs, ObjExt.fs), webpack will trigger a recompile appropriately, except when you change the function:

[<Extension>]
type GenericExt () =
    [<Extension>]
    static member inline Also(source, f) = f source; printfn "oosh"; source

It's a rather silly function and definitely not functional style, but it illustrates the point. Simply try to change the string that it prints and you'll notice webpack react, but not find any changes to actually recompile and running the program still shows the original string.

If you run, from a separate terminal (leaving Fable running in the first terminal), ./fable_js (another batch file that simply runs fable-splitter), and look at the generated ExtensionExample\Main\fable_js\src\ObjExt.js file, you'll see that the class is basically ignored:

import { setType } from "../fable-core/Symbol";
import _Symbol from "../fable-core/Symbol";
export class GenericExt {
  [_Symbol.reflection]() {
    return {
      type: "ExtEx.Core.ObjExt.GenericExt",
      properties: {}
    };
  }

  constructor() {}

}
setType("ExtEx.Core.ObjExt.GenericExt", GenericExt);
export const value = 123;

And at the call-site in ExtensionExample\Main\fable_js\src\Main.js:

import { middle, ABC, f } from "./Util";
import { printf, toConsole } from "../fable-core/String";
import { value } from "./ObjExt";
(() => {
  const $var1 = f(new ABC(0)) === f(middle);

  (function (x) {
    toConsole(printf("A is middle: %A"))(x);
  })($var1);

  toConsole(printf("oosh"));
  return $var1;
})(), void 0;
toConsole(printf("value : %A"))(value);

The function is simply in-lined with no actual call occurring.

Related information

Windows 10 x64
yarn 1.9.4
npm 5.6.0
node 8.11.4
Fable 1.3.17

Is this just the kind of quirk that we'll have to watch out for, or will this sort of thing be resolved at some point?

All 5 comments

Oh! I just saw it after quite a few hours of staring at this same code, but not until after I posted this issue, of course :^)

The inline modifier is causing this, which is definitely something I would see as reasonable behavior. Please feel free to close this if this is indeed working as designed.

Maybe the inline modifier should be ignored altogether though somehow? For a JS target, it doesn't seem to do much other than duplicate code.

Unfortunately the inline modifier cannot be ignored as it's important in many situations to resolve types, particularly with SRTP but also with generics as generic info is erased in the JS runtime. I'm aware of the issue and did try to add a file dependency when a call is inlined so Webpack would recompile the dependent file in the inline function changes. However, we had some weird problems because of this and had to remove it. Maybe it's fixed in Webpack 4, I'll give it a try.

I think I found the issue, the normalized path separator was causing problems in Windows. @SirUppyPancakes Can you please try with fable-loader 2.1.1 and fable-compiler 2.1.7 and check if editing an inline function triggers a recompilation of files referencing it?

Yep looks good after upgrading :)

It happened there was still an issue with the order of the file recompilation 馃槄 Please update to fable-compiler 2.1.8 if you still have issues.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

funlambda picture funlambda  路  4Comments

ncave picture ncave  路  3Comments

nozzlegear picture nozzlegear  路  3Comments

alfonsogarciacaro picture alfonsogarciacaro  路  3Comments

theprash picture theprash  路  3Comments