Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Now that we have Javascript modules, is all this trickery on top of a library like this one still needed?

This is how the Chart.js code begins:

    (function (global, factory) {
    typeof exports === 'object' && typeof module !== 
    'undefined' ? module.exports = factory() :
    typeof define === 'function' && define.amd ? 
    define(factory) :
    (global.Chart = factory());
    }(this, (function () { 'use strict';
    ... now comes all the code ...
I have no idea how to read this, what this means and how to invoke a construct like this.


> 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.


This is legacy UMD code to make the file compatible with AMD, CommonJS, and globals, but not standard JS modules.

Please file an issue! Libraries need to upgrade to JS modules ASAP.


That is an UMD bundle. What is more disappointing is that Chartjs itself seems to be written in ES5.


Why it still works, no need to refactor the code for the sake of refactoring if this is free work.

Change to ES modules would be welcome though.


They seem to be using Rollup for builds, which supports ESM output, so they wouldn't even need to do any refactoring for that. Couple of configuration changes would suffice.


I'd be happy to review any PR to improve our rollup & package.json config as long as it's backwards compatible with the documented methods of using Chart.js: https://www.chartjs.org/docs/latest/getting-started/integrat...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: