fix(618): handle remaining wasm panics, and expose is_valid_flux() API

[wiedld]

Closes #618

Done:

• wasm start now triggers logger setting at the wasm root (on load in browser). Confirmed will allow logging in LspServer and utils module.
• update test fixtures, to make more explicit what the parse() contract does.
  • note: we are misusing parse() as a validation method in the UI. Which is wrong.
• expose an is_valid_flux() method which can be used for validation in the UI

Payload comparison:

The size of our wasm can impact network load times. With the changes made here, the release build has an increase in 25kB size.

[wiedld]

Chose wasm-logger over console-log lib, due to the reported build size.

[appletreeisyellow]

Thanks for adding the test case! I have one question below

[appletreeisyellow]

I'm very new to wasm. Just trying to understand. What does fluxlang do here? To expose is_valid_flux() API? I thought is_valid_flux() is already included in wasm-bindgen.

[wiedld]

is_valid_flux() uses the lang module, which is not included in the wasm without this feature.

But then did a build size sanity check, to make sure the wasm is still an ok size.

[appletreeisyellow]

Got it! Thanks

[wiedld]

So...lesson learned.
Although the #[wasm_bindgen(start)] annotation runs in our test suite, that is because the test suite is on target node. It does NOT work when imported to the browser, because that is built using target browser and then transformed via webpack.

chain of actions:

• The #[wasm_bindgen(start)] annotation runs the start method once on module eval (import).
• When building to the bundler target, the resultant compiled code is wasm.__wbindgen_start();
• Then webpack transforms this code into WEBPACK_IMPORTED_MODULE_1__.__wbindgen_start(), where the annotated method is called on module import.
• BUT --> it does not get called. And the wasm silently dies (does nothing else).

reason for failure?

• We are building our wasm to target bundler, which has no sideEffects.
• No side effects --> webpack only looks for imported functions, and will not run eval on the imported module (a.k.a. will never call the start method).
• Observed behavior:
  • #[wasm_bindgen(start)]
    --> LSP silently does nothing.
  • #[wasm_bindgen(start)] + sideEffect: true
    --> webpage silently died on load
  • change UI to @influxdata/flux-lsp-node
    --> clearly fails, since node targets have fs, etc
  • build with -t web + UI using WasmPackPlugin
    --> will hit a double declaration of the start method init (bug also seen in many other open wasm-pack issues)

.

So what is the conclusion? Do it the manual way:

• go back to setting the logger on LspServer creation.
• call the init() method manually, and globally, on import into the UI.

[wiedld]

Fixed.

On version bump in UI, we then need to update this file to:

1. init the log

   import {
     parse as flux_parse,
     format_from_js_file as flux_format_from_js_file,
     initLog,
   } from '@influxdata/flux-lsp-browser'
   
   initLog()
   

2. the exported parse() should also run is_flux_valid() first

[wiedld]

Since we no longer include the console_log just for dev build, we don't need to re-bind the BUILD_MODE_ARGS

[appletreeisyellow]

Thanks for the explanation!