Typescript issue with moduleResolution: NodeNext

[Mister-Hope]

Expected behavior

node_modules/.pnpm/chart.js@3.9.1/node_modules/chart.js/auto/auto.mts(1,23): error TS2307: Cannot find module '../types/index.esm' or its corresponding type declarations.

Current behavior

Cuurently chart.js 's declaration files can not work with moduleResolution: NodeNext when targeting esm.

(Both with chart.js and chart.js/auto)

I think that al least chart.js/auto should respect latest typescript requirements on esm.

See https://www.typescriptlang.org/docs/handbook/esm-node.html for more details. This is somthing ts adds support in 4.7

Reproducible sample

Not related to chart runtime code

Optional extra steps/info to reproduce

No response

Possible solution

1. Add .js externsion for all files in source code
2. Use tools like rollup=plugin-dts to bundle a .d.mts declaration file for auto.mts to avoid a relative import without extension instead of creating a declaration wrapper.

Context

No response

chart.js version

all chart.js version are having this issue

Browser name and version

No response

Link to your project

No response

[LeeLenaleee]

Duplicate of #10599

[Mister-Hope]

Nope, again: all chart.js version has this issue.

You are definitely closing issues too casually, as I do think that we are reporting different things.

[kurkle]

Nope, again: all chart.js version has this issue.

Only v3.9 has anything with .mts extension, so all versions can not possibly have this particular issue.
The v3.0+ src folder does not contain .js in imports, but you should not be using the src anyway (its not included in the package, and is not considered public api or to be stable).

You are definitely closing issues too casually, as I do think that we are reporting different things.

The errors reported are identical in these issues. The tooling used is different, but its the same issue anyway.

[Mister-Hope]

Cuurently chart.js 's declaration files can not work with moduleResolution: NodeNext when targeting esm.

(Both with chart.js and chart.js/auto)

Are you 2 guys kidding me?

What I am reporting is that

TypeScript requires .(c|m)?js extension in All Relative Imports under moduleResolution: NodeNext added in TS4.7+ to support ESM.

But all versions of chart.js is NOT bundling type declarations and does NOT add .js in declaration imports.

Is everything clear enough for you 2 now?

Why should it be the same thing with the issue you referenced?

[kurkle]

Thank you for the clarification.

I did not recall the types folder imports were without extension.

From the typescript docs its not obvious if imports pointing to a directory would read the index.d.(m|c)ts or does it need to be explicit too? (v4 auto package imports from a directory currently)

v4 is going to emit the types:
https://github.com/chartjs/Chart.js/blob/master/tsconfig.json#L16-L18

I'm not sure if there is a will to update the type imports for v3. As always you are welcome to create a PR for that against the 3.9 branch.

And before you ask, there is no date for v4. It could be soon or later - because this is an open source project and for it to go forward, it needs time investment from contributors.

[Mister-Hope]

From the typescript docs its not obvious if imports pointing to a directory would read the index.d.(m|c)ts or does it need to be explicit too?

For the latest moduleResolution NodeNext, yes, because in esm package you do have to use

import a from './dir/index.js';

And import a from './dir' or import a from './dir/' do not work. So typescript is asking the samething in nodenext or node16 in source code and declaration files( because declaration files could be source code while using by outher files).

Since we are outputing esm bundle in 3.9, I was thinking we'd better to convert the exisiting code to a valid esm code in typescript.

But as you are mentioning v4, I looked at the main branch, if you are planing to release v4 very soon (I probably mean in 30 days) I think we can make the changes only in v4, and make a depercated message in 3.9 esm bundle to tell users it's broken.

It's not very hard to make a workaround though yarn patch or pnpm patch or patch-packages(for npm) for users like me.

If anyone meets the same issue and needs a workaround, I would be happy to leave some pieces here.

[dangreen]

@kurkle @LeeLenaleee I will research this issue soon.