v3: consider changing export logic for esm modules

Feature Proposal

the in the v3 version the enhanced Chart module is exported as the solely (default) export from the library.


As an alternative one could have the following structure:

import ChartChart from './core/core.controller';
export { default as Chart } from './core/core.controller';
import DatasetController from './core/core.datasetController';
export { default as DatasetController }  from './core/core.datasetController';

class Chart extends ChartChart {
Chart.DatasetController = DatasetController;

export default Chart;

the purpose around the Chart class is that only the default export has all the dependencies but not the class itself.

Feature Use Case

I want to prepare for tree shaking and thus only import things that I really need. e.g.,

import {DatasetController} from 'chart.js';

class MyController extends DatasetController {

note: while this works already with some synthetic imports (by rollup, …) it is not standard conform.

Possible Implementation

Author: Fantashit

2 thoughts on “v3: consider changing export logic for esm modules

  1. what about splitting up this issue, this one contains the discussion about how to structure the ESM build and another one about how to do the registration process for different components: controller, scales, elements, plugins

Comments are closed.