ESM compatibility - unable to build #256
Comments
|
Thanks for reporting! I've opened a PR #257 which I think should resolve it, based on some reading I did, but I haven't yet tested that it resolves the issue in a node project. Once I do, I'll plan to merge and publish a new version. |
Should resolve #256 Both `@mui/icons-material` (mui/material-ui#35233) and `lodash` (lodash/lodash#5107) have problems being imported in a consuming package when using ESM. The workarounds attempted in #258 almost seemed to work (didn't break a downstream bundled package using Vite), but still caused problems for the original example node application https://codesandbox.io/p/devbox/pensive-volhard-hyhtls, with errors like: ``` Error: Cannot find module '/path/to/mui-tiptap-in-node/node_modules/@mui/icons-material/esm/FormatColorFill ``` This approach is inspired by what tss-react does https://github.com/garronej/tss-react/blob/f5351e42e33f35f18415cfc1ffc6b08eb8ce4d25/package.json (e.g. see here garronej/tss-react@4699702 and garronej/tss-react#164). With this change, this code now works in the node context (though slightly odd): ``` import pkg from "mui-tiptap"; const { FontSize, HeadingWithAnchor, ResizableImage, TableImproved } = pkg; ```
Should resolve #256. Both `@mui/icons-material` (mui/material-ui#35233) and `lodash` (lodash/lodash#5107) have problems being imported in a consuming package when using ESM. The workarounds attempted in #258 almost seemed to work (didn't break a downstream bundled package using Vite), but still caused problems for the original example node application https://codesandbox.io/p/devbox/pensive-volhard-hyhtls, with errors like: ``` Error: Cannot find module '/path/to/mui-tiptap-in-node/node_modules/@mui/icons-material/esm/FormatColorFill ``` This approach is inspired by what tss-react does https://github.com/garronej/tss-react/blob/f5351e42e33f35f18415cfc1ffc6b08eb8ce4d25/package.json (e.g. see here garronej/tss-react@4699702 and garronej/tss-react#164). With this change, this code now works in the node context (though slightly odd): ``` import pkg from "mui-tiptap"; const { FontSize, HeadingWithAnchor, ResizableImage, TableImproved } = pkg; ```
|
@tehbelinda I've spent an inordinate amount of time trying to resolve this, and it's shockingly difficult to find a working solution. CJS vs ESM packaging/resolution is a frustrating mess! My original solution #257 didn't seem to work in practice, and #258 seemed to work in consuming bundled packages but then I tested on your node project where it still failed (even after trying to update imports for icons-material and lodash) 😢. So #259 seemed to be an approach that should hopefully work for various end-users, forcing CJS in the node environment. I wouldn't be surprised if mui-tiptap still does not (and has never) properly packaged for ESM despite exporting files for that context, due to the quirks/incompatibilities with ESM in Published in v1.9.6. If you happen to have a better suggested fix or if this is still causing problems, I'd greatly appreciate suggestions on how it can be handled! In the end, you'll want to use this syntax: import pkg from 'mui-tiptap';
const { FontSize } = pkg; |
|
appreciate you digging into this, it is working! only strange thing is that I had to add not sure if this helps as you may have already seen this and I have never tried it myself, but this post suggests using rollup to support both: https://stackoverflow.com/a/75348391 |
|
@tehbelinda Glad it's working! Yeah, that's expected, since As for that Stack Overflow post, I did actually see that very post and did try rollup (via Vite library mode as mentioned in #258 (comment)). I didn't go too far with it, since it seemed less capable than |
When `"type": "commonjs"` is specified in our package.json, it
apparently causes the following problem in NextJS:
```
Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (1:0)
> export { default as ControlledBubbleMenu, } from "./ControlledBubbleMenu";
| export { default as LinkBubbleMenu, } from "./LinkBubbleMenu";
| export { default as MenuBar } from "./MenuBar";
```
This is odd, since we indeed *are* using "commonjs" type, as that's the
default, but it seems that fortunately merely omitting this resolves
import errors in NextJS, and still supports NodeJS.
Should resolve #264,
removing one of the changes from
#259, while still
hopefully keeping #256
fixed.
When `"type": "commonjs"` is specified in our package.json, it
apparently causes the following problem in NextJS:
```
Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (1:0)
> export { default as ControlledBubbleMenu, } from "./ControlledBubbleMenu";
| export { default as LinkBubbleMenu, } from "./LinkBubbleMenu";
| export { default as MenuBar } from "./MenuBar";
```
This is odd, since we indeed *are* using "commonjs" type, as that's the
default, but it seems that fortunately merely omitting this resolves
import errors in NextJS, and still supports NodeJS.
Should resolve #264,
removing one of the changes from
#259, while still
hopefully keeping #256
fixed.
Describe the bug
When including extensions from mui tiptap in a node js environment with es modules, it fails to build
The error is:
Tried the default as suggested, but then that resulted in:
To Reproduce
https://codesandbox.io/p/devbox/pensive-volhard-hyhtls
Steps to reproduce the behavior:
npm startto see the first errornpm startagain, see the second errorExpected behavior
Running
npm startshould successfully build and run the index.ts code.Screenshots
N/A
System (please complete the following information)
Additional context
I'm trying to convert HTML into a Tiptap format on a Hocuspocus nodejs server with TiptapTransformer (https://tiptap.dev/docs/guides/output-json-html), and would like to use the same Mui TipTap extensions that we use on our frontend for compatibility. I can import the rest of the Tiptap extensions without issues.
I noticed this package.json does have separate exports for import/require, so it seems like ESM should work. However it doesn't have
"type": "module",could that be an issue?The text was updated successfully, but these errors were encountered: