Dependencies need to be ESM

[benmccann]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

all

Link to runnable example

No response

Steps to reproduce

Provided in sveltejs/kit#1961

Expected behavior

All dependencies should be ESM since this package declares "type": "module". The package should work out-of-the-box with SvelteKit and Vite

This can be fixed by distributing an ESM version of is-buffer and extend or by removing those dependencies from this library since they have minimal usage. I've sent a PR for is-buffer feross/is-buffer#43 though I don't know yet whether it will be accepted

This could be added a sub-task to #121

Actual behavior

Vite encounters CJS dependency of this ESM module and fails with the message module is not defined as described in vitejs/vite-plugin-react#30

Runtime

Node v14, Other (please specify in steps to reproduce)

Package manager

npm v7

OS

Linux

Build and bundle tools

Vite

[ChristianMurphy]

Thanks for reaching out @benmccann!

It's also worth noting the Vite is planning to fix this so it would work by default vitejs/vite#3024 (comment) and there is a work around available today without needing to change packages vitejs/vite#3024 (comment)

---

This can be fixed by distributing an ESM version of is-buffer and extend

I'm happy to see improvements in unified's dependencies. 👍
Thanks for opening feross/is-buffer#43!
Would you be interested in opening a pull request to extend as well?

---

by removing those dependencies from this library since they have minimal usage

I'm happy to change unified's dependencies, if there are security, performance, or stability benefits. 👍

I'm cautious changing dependencies only for the sake of working around a short term bug in a particular tool chain.
As more packages adopt ESM, module format bugs in several tool chains have been uncovered (most outlined with workarounds in: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c)

We definitely want to offer a path for folks to upgrade across a variety of tool chains.
Baking workarounds into unified long term to address short term bugs in particular build tools, doesn't feel like an appropriate or sustainable approach.
For short term problems, where upstream fixes are not immediately possible, documentation/guides feel more appropriate.

Happy to discuss dependency changes or help with documentation!

[raulfdm]

@ChristianMurphy , @benmccann ... I've opened this PR to help out: justmoon/node-extend#57

[wooorm]

All dependencies should be ESM since this package declares "type": "module". The package should work out-of-the-box with SvelteKit and Vite

No, I disagree. type: module is a Node.js thing. Node allows CJS dependencies. If your bundler supports type: module, then it should also allow CJS dependencies.

Of course: hopefully in the future we can ditch CJS! But Vite is broken. Not unified.

---

As Christian mentioned, we can discuss how to teach folks how to use Vite with npm and unified, but I’m closing this because it’s not actionable.

[205g0]

For short term problems, where upstream fixes are not immediately possible, documentation/guides feel more appropriate.
...
we can discuss how to teach folks how to use Vite with npm and unified, but I’m closing this because it’s not actionable.

This would be helpful, I can't get unified to work in the SSR part of SvelteKit (Vite-based): I get __vite_ssr_import_2__.unified is not a function

When I have:

vite: {
  optimizeDeps: {
    include: ['unified'],
  },
},

I get module is not defined at ...is-buffer...