Support fully specified import paths in ESM output for better Node.js and Webpack compatibility #827

Is your feature request related to a problem? Please describe.

maxGraph v0.19.0 provides an ESM build, but its integration is not smooth:

Webpack (as of v0.10.1) requires a workaround to make it work: f5c43dee59678ec6ade66ff92ba40c15ec7b4b38

Node.js can't use the ESM output directly because import paths are missing the .js extension.
Example error as shown in #826:

[ERR_MODULE_NOT_FOUND]: Cannot find module '/dev/maxGraph/packages/core/lib/esm/view/mixins/_graph-mixins-types'
imported from /dev/maxGraph/maxGraph/packages/core/lib/esm/index.js

This is expected behavior according to Node.js ESM rules: https://nodejs.org/docs/latest-v16.x/api/esm.html#import-specifiers

A file extension must be provided when using the import keyword.

Webpack replicates this behavior in .js/.mjs files within packages marked as type: module: webpack/webpack#11467 (comment)

CommonJS support (added in v0.20.0 via #824) does not help in this case.

Errors detected with "Are the types wrong?"

This tool shows the problem when using the TypeScript node16 module resolution: the js extension are missing in imports.
See https://arethetypeswrong.github.io/?p=%40maxgraph%2Fcore%400.20.0

Describe the solution you'd like

• Add .js extensions in all import paths in ESM output.
• Enforce extension usage to prevent regressions.
• Ensure the Node.js ESM example (feat: add CommonJS support to npm package #826) works without error.
• Remove the need for workarounds in Webpack setups.
• This would also improve compatibility with browser usage (see How to use maxgraph directly in a web page #462), even if that's not officially supported.

Describe alternatives you've considered

• Keeping the workaround in Webpack config - not ideal.
• Avoiding ESM in Node.js altogether - but headless usage with Node is still useful.

Additional context

TypeScript support
maxGraph is written in TypeScript, so .js extensions in imports look weird. But recent TS versions support this:

• allowImportingTsExtensions (TS 5.0) https://www.typescriptlang.org/tsconfig/#allowImportingTsExtensions
• rewriteRelativeImportExtensions (TS 5.7) https://www.typescriptlang.org/tsconfig/#rewriteRelativeImportExtensions

Also, moduleResolution: "node16" forces extensions: https://www.typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option

ESLint
We can enforce and auto-fix with ESLint plugins:

• import/extensions - manual fix only
• n/file-extension-in-import - supports auto-fix

To limit noise, this rule could be scoped to the core package only.

Related issues

• How to use maxgraph directly in a web page #462: ESM usage in browser
• Running maxgraph headlessly #761: Node.js compatibility

Please notify those threads once the change is implemented.

Possible implementation plan

• Reproduce the Webpack issue by removing the workaround in examples
• Fix the Node.js ESM usage (feat: add CommonJS support to npm package #826)
• Use tsconfig.moduleResolution = node16. Not needed, the build workflow tests this configuration with https://github.com/arethetypeswrong/arethetypeswrong.github.io/tree/main/packages/cli
• Add ESLint rule and autofix
• Apply changes only in packages/core
• Consider adding a CI build step to run https://github.com/arethetypeswrong/arethetypeswrong.github.io/tree/main/packages/cli