-
Notifications
You must be signed in to change notification settings - Fork 199
Description
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.jsThis 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
.jsextensions 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/#allowImportingTsExtensionsrewriteRelativeImportExtensions(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 onlyn/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
