ES5 AMD (i.e. Rhino/NetSuite compatible) build?

[ShawnTalbert]

trafficstars

Hello, I'd love to use RxJS in NetSuite (which uses an ES5.1 compatible version of the Rhino JS engine behind the scenes).

I've tried several of the existing builds, but none seem to work. The most promising one for this ES5.1 /AMD compatible environment seemed to be @reactivex/ix-es5-umd but it fails when their loader tries to load it with (I also tried using Ix.dom.js:

{"type":"error.SuiteScriptModuleLoaderError","name":"UNEXPECTED_ERROR","message":"missing : after property id (/SuiteScripts/Ix.dom.internal.js#220)","stack":[]}

I realize ES5.1 is a bit old, but this is my ask for a build we can use in this environment (an environment which I don't control.)

p.s. I also noticed references to Symbol.iterator in the ES5 build which isn't part of ES5 so that confuses me a bit. , so not sure if the ES5 build is polyfilling that or what.

[trxcllnt]

Hi @ShawnTalbert, yeah no worries this shouldn't be a problem. Just curious, do you see the same error if you import the Ix.dom.js file as well? Ix.internal is a file we build with extra exports so we can run tests on all the operator flavors (and it'll probably go away after #264 is finished).

If you are still seeing the error, are you consuming the UMD bundle with an AMD loader? I just remembered there's a fix to the AMD part of the UMD header that I haven't published yet. You can try and see if manually editing line 3 of the JS file like this fixes it:

-    typeof define === 'function' && define.amd ? define(['Ix'], factory) :
+    typeof define === 'function' && define.amd ? define(['exports'], factory) :

[ShawnTalbert]

Thanks @trxcllnt! Although YES Rhino is being used in an "AMD" envrionment in my case, unfortunately NO the fix above didn't change anything in regards to my error.

I do know that (recent versions of) TSC's compiled output code header for UMD targets tends to work ok in this 'AMD' environment.

p.s. thanks for the clarification on the internal version of the file - I couldn't find any documentation on which file I should try in this environment so I tried all of them. :) I do see package.json references Ix.dom as "main" but that's all the documentation I could find on what each of the built files are for.

Also notable that this environment isn't a browser - so I'm concerned that is the dom in that file name implies Browser DOM which isn't available in Rhino as-is?

[ShawnTalbert]

I also just tried Ix.dom.es5.min from the main ix package - same error :( Perhaps I can play around with the "TS" target and further compile it to UMD? It would benice if a pre-built version of the lib worked with the AMD environment I'm trying to use.

Upon futher experiments, looks like there is a polyfill for Symbol that it didn't recognize, and I assume something for ArrayBuffer as well (since both those are not in ES5 but referenced in the es5 build)?

[trxcllnt]

The es5/umd bundle is compiled via closure-compiler, and it's possible closure is minifying in a way that's not compatible with Rhino. I'm pretty sure closure is adding a few polyfills (Symbol, Promise, AsyncIterable), which it seems like you're noticing.

Can you use one of the non-minified targets, like es5-cjs? It's been a while, but I thought I recalled amd.js had some sort of common-js compatibility mode for things like this.

[ShawnTalbert]

One thing I eventually discovered is [this setup of] Rhino doesn't like reserved words as idenfifiers, so one location had default() as a property getter and it failed. Getting past that is where the Symbol and ArrayBuffer popped up as issues.

I don't get any control over the "AMD-like" environment I'm trying to use this code in (NetSuite). Technically this environment does support require.config() but it seems unreliable and isn't used much here.

Do you think it would be difficult to have TSC compile it all (with target="es5" and module ="UMD" or "AMD") then bundle those results into a single file. I spent a little time trying to reverse engineer the current project build but it's a bit complex.

[trxcllnt]

Yes the CC build is a bit convoluted because closure-compiler is... special. To get it to work we first have tsc compile the source to ES6 + ESModules, then have closure minify that down to es5/umd. I think the "module": "umd" in tsc is newer than our build config, so I haven't tried it yet.

One feature of our setup is we run all the tests on each compiled result rather than the source. If you could help by getting a minimal repro example bootstrapped, I could see what's going wrong and help reverse-engineer the build requirements from there. After that I can put it into our CI scripts to ensure no regressions. I'm on ubuntu 1804, so ideally something that runs in there (or something we can stick in a docker container). I also have access to an OS X box, but no windows unfortunately.

[ShawnTalbert]

thanks Paul, I haven't needed to stand this runtime up myself but I'll see what I can come up with for a minimal docker setup. Out of town lately (windows only mode) but will see what I can whip up on linux when I returns. Thanks for offering to look into it. I really would like to try out the library in this environment.