5 ms·

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

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.

fleetfox 7y ago
That is an UMD bundle. What is more disappointing is that Chartjs itself seems to be written in ES5.
- ergo14 7y ago
  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.
  - vimslayer 7y ago
    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.
    - benmccann 7y ago
      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/integration.html https://www.chartjs.org/docs/latest/getting-started/integrat...
tjwds 7y ago
> 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 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/8883b20d5981518bad66497f0466acb5 https://gist.github.com/tjwds/8883b20d5981518bad66497f0466ac...
- TicklishTiger 7y ago
  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';
  - ng12 7y ago
    Yes, this is the point of that code. It's boilerplate to ensure the module loads in different environments.
    - spankalee 7y ago
      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.
      - ng12 7y ago
        I'm not sure what you mean. Obviously UMD cannot support native es6 modules since they're syntactical invalid for non-es6 applications.
        spankalee 7y ago
spankalee 7y ago
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.

fleetfox 7y ago

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

ergo14 7y ago
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.
- vimslayer 7y ago
  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.
  - benmccann 7y ago
    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/integration.html https://www.chartjs.org/docs/latest/getting-started/integrat...

tjwds 7y ago

> 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 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/8883b20d5981518bad66497f0466acb5 https://gist.github.com/tjwds/8883b20d5981518bad66497f0466ac...

TicklishTiger 7y ago
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';
- ng12 7y ago
  Yes, this is the point of that code. It's boilerplate to ensure the module loads in different environments.
  - spankalee 7y ago
    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.
    - ng12 7y ago
      I'm not sure what you mean. Obviously UMD cannot support native es6 modules since they're syntactical invalid for non-es6 applications.
      - spankalee 7y ago

spankalee 7y ago

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.