any one having issues with NetSuite App Version [ 2018.2.0.147 ] using UMD support libraries and script. got define.amd: true globally in this update.

we compile (TypeScript) all our scripts to UMD target and it all works.

I have some old client scripts in 1.0 compiled from coffeescript that are tossing errors all over the place.

compiled to UMD format @dmashburn3?

I'm actually just learning what UMD format is now. I inherited the scripts and this process, so I'm stuck playing catch up.

I'd throw coffeescript out the window, but that's just my opinion

Ha, believe me, I'm trying to rewrite all of it. There is just a lot. Sorry, thought my errors might be related. Maybe not though.

My unsurprising recommendation would be to replace the coffeescript with TypeScript 🙂

i m using angular1 with suitescript 1.0 and due getting define.amd: true globally in NetSuite App Version [ 2018.2.0.147 ] (typeof define === "function" && define.amd). angularJs treated as amd compatible module. and wont work with SS1.0.

yes, NS has a history of putting questionable things in the global namespace,

window

for server side scripts is another. sounds like you need to modify your script header to perhaps remove AMD detection

@stalbert i have removed the amd detection for now. but this is not a solution.

I have old SS1 scripts that use third party libs. The third party libs use UMD. When they load they check

typeof define === 'function' && define.amd

to detect whether they should use

define(factory)

or to add a global var to window. On my sandbox it appears NetSuite changed up the load order of requirejs, so now these UMD libs are finding the above condition to be true and are loading themselves incorrectly. On my live account I don't have this behavior(yet).

@jkabot same here with me.

perhaps it's just a sandbox mistake?

So far I have only seen it for client scripts on our sandbox.

ok that's a bit more comforting. Hoping at worst it only breaks all (qualifying) client scripts 🙂

To give a bit more info: I have some third party libs that are added to the page using

<script src="..." >

in inline html field. In SS1 this seemed like a fine way to include another lib for a client script. This was before SS2 was announced and we knew netsuite would introduce requirejs. The third party libs use the UMD pattern to decide whether to call

define

or to add a variable to the global scope. The SS1 client scripts expect them to add to the global scope. Since the browser is supposed to download and run non-async

<script src="...">

based on the order that it encounters them in the document, and these libs were previously working fine, my guess is NetSuite moved requirejs

<script>

higher up in the document.

makes sense @jkabot though we've always stuck to the 'official' way to include scripts via the UI TAB on the script record.