Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force node to use CJS to get around dependency import errors, and validate package types in CI #259

Merged
merged 3 commits into from
Aug 21, 2024

Conversation

sjdemartini
Copy link
Owner

@sjdemartini sjdemartini commented Aug 21, 2024

Third attempt to resolve #256 😅 (should supersede #258 and #257, see the former for more details/discussion)

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 (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;

and is considered valid by arethetypeswrong:

❯ npx @arethetypeswrong/cli@0.15.4 --pack

mui-tiptap v1.9.5

Build tools:
- typescript@^5.1.6
- vite@^5.3.1

 No problems found 🌟


┌───────────────────┬──────────────┬────────────────────┐
│                   │ "mui-tiptap" │ "mui-tiptap/icons" │
├───────────────────┼──────────────┼────────────────────┤
│ node10            │ 🟢           │ 🟢                 │
├───────────────────┼──────────────┼────────────────────┤
│ node16 (from CJS) │ 🟢 (CJS)     │ 🟢 (CJS)           │
├───────────────────┼──────────────┼────────────────────┤
│ node16 (from ESM) │ 🟢 (CJS)     │ 🟢 (CJS)           │
├───────────────────┼──────────────┼────────────────────┤
│ bundler           │ 🟢           │ 🟢                 │
└───────────────────┴──────────────┴────────────────────┘

CJS vs ESM package resolution is an absolute mess—sad there's so much fragmentation and trouble getting things to play nicely with third party packages and different environments 😞

Per recommendation from publint.  https://publint.dev/rules#use_type

> The package does not specify the "type" field. NodeJS may attempt to detect the package type causing a small performance hit. Consider adding "type": "commonjs".
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;
```
@sjdemartini sjdemartini merged commit aafca00 into main Aug 21, 2024
1 check passed
@sjdemartini sjdemartini deleted the use-cjs-in-node branch August 21, 2024 00:43
sjdemartini added a commit that referenced this pull request Sep 15, 2024
This effectively reverts the main change in
#259
with a goal of supporting NextJS again, to resolve
#264
sjdemartini added a commit that referenced this pull request Sep 15, 2024
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.
sjdemartini added a commit that referenced this pull request Sep 15, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ESM compatibility - unable to build
1 participant