Comment by tjwds | Hacker News Reader

Comment by tjwds | Hacker News Reader

Parent Full thread

> is all this trickery on top of a library like this one still needed?

If the library is imported in the way that the article recommends in step two, it's not actually loaded as an ES6 module. This code checks to see if we're currently acting as a module and accordingly makes sure that the library is available as a global object. See this link for some examples: https://devhints.io/umdjs

> I have no idea how to read this ...

I tried to add some comments [0] which will hopefully help!

[0] https://gist.github.com/tjwds/8883b20d5981518bad66497f0466ac...

Nowadays, I either include javascript as a module or as a module dependency. I am still not sure if these will work with the given code:

As a module:

    <script type="module" src="Chart.js"></script>

As a module dependency:

    import * as chart from 'Chart.js';

Yes, this is the point of that code. It's boilerplate to ensure the module loads in different environments.

UMD does _not_ support standard JS module imports. The UMD code won't detect `exports` or `define` and will write to globals instead of producing any exports.

I'm not sure what you mean. Obviously UMD cannot support native es6 modules since they're syntactical invalid for non-es6 applications.

The GP wants to import into JS modules, and you said:

> Yes, this is the point of that code. It's boilerplate to ensure the module loads in different environments.

but the UDM header does not allow the module to load in JS modules. So I'm not quite sure what you meant actually. The header does nothing for standard modules.

Reply on news.ycombinator.com