[IGN-12300]Support for ES Modules?

Module Development
1

I can't find a way to use an ES Module as a BrowserResource.

  1. When marked as BrowserResource.ResourceType.JS, there isn't way to add the type="module" attribute to the inserted HTML:
 <!-- Current --> 
<script type="application/javascript" src='...'></script>

 <!-- Desired --> 
<script type="module" src='...'></script>
  1. If you add a resource with extension .mjs, Ignition does not serve the file with the correct Content-Type header, leading to an error:
Refused to execute script from \'https://.../my-resource.mjs\' because its MIME type (\'\') is not executable, and strict MIME type checking is enabled.

Anyone gone down this road before?

If it isn't supported, it'd be nice if it was. I think this would give me the isolation needed to run multiple versions of a JavaScript library in the client.

https://caniuse.com/es6-module

2

I'm 99% confident the answer is just "you cannot", right now.

Can you give me the elevator pitch on ES modules, as a (deliberately) frontend-ignorant person? It's something-something JS packaging, and that's the extent of my knowledge.

It would be trivial to add an enum to ResourceType that ultimately emits different HTML, but I'm not sure if that bandaid is the "right" way to fix this problem.

1 Like
3

Huh. I'm a bit surprised that is an Enum. Can't even supply a custom mime type. :frowning:

4

Yeah, that's where I'm wondering if it's not better to rethink the whole way ResourceType works...but that then becomes a larger change that I can't as readily "sneak in" :person_shrugging:

1 Like
5

Point. That's probably a big breaking change. Has to be done to get to things like Web Assembly.

1 Like
6

Ha, I just know enough to get what I need done and then get out :laughing:.

Here's my TLDR take on ES6 modules:

  1. JavaScript is a mess.
  2. There have been many different strategies for importing and using libraries/modules of code (CJS, AMD, UMD, etc). Each of these strategies was created to target a specific use-case of JavaScript (browser vs Node vs whatever), and none of them are actually part of the JavaScript language.
  3. ES6 modules were introduced in the ECMAScript 2015 standard as an addition to the language to standardize how libraries/modules of code are shared.
  4. With ES6 modules you can use the same import/export syntax in the browser as you can in server runtimes, to import code from other JavaScript files. This gets you:
    • Code isolation (modules don't need to pollute the global namespace).
    • Tree-shaking (only load what you need).
    • Removes the need for complicated bundling.
    • Generally makes JavaScript behave more like a real language.

If any of this is wrong, hopefully Cunningham's Law will kick in.

The code isolation feature is what I'm after.

2 Likes
7

Well, I looked into the codebase and it's involved enough I'm not comfortable just YOLO-ing the changes into 8.3, so I made a ticket to do it "right". The most likely scenario is that we just add an enum for ES modules that will then emit the right HTML on the final page. Since that's just adding an enum entry, it's not a breaking change, so even if we don't get to it before 8.3 it could still happen in an 8.3.X release, which is a bonus.

5 Likes
8

:+1:

In the mean time, I'm gonna try to use a "bootstrapping" resource to add the HTML to load the "real" resource as a module.

1 Like