tihs package uses non-ESM dependencies in a way that is not compatible with pure ESM environments

[NullVoxPopuli]

Initial checklist

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

Affected package

unified

Steps to reproduce

I'm building a library that uses unified. So I can't mandate consumers have specific exceptions for unified using cjs dependencies in the dependency graph.

Try vite 6, or rollup with a project that uses unified (or any other ESM-based packager (esm.sh with no pre-build, for example))

Problem comes from here:

unified/lib/index.js

Line 344 in 45d8fa5

import extend from 'extend'

I did see this issue: #153
But, because I'm a library author, not an app dev, the solutions in that issue are not possible.

Actual behavior

This error:

[!] RollupError: ../../node_modules/.pnpm/unified@11.0.5/node_modules/unified/lib/index.js (350:7): "default" is not exported by "../../node_modules/.pnpm/extend@3.0.2/node_modules/extend/index.js", imported by "../../node_modules/.pnpm/unified@11.0.5/node_modules/unified/lib/index.js".
https://rollupjs.org/troubleshooting/#error-name-is-not-exported-by-module
../../node_modules/.pnpm/unified@11.0.5/node_modules/unified/lib/index.js (350:7)
348: 
349: import {bail} from 'bail'
350: import extend from 'extend'
            ^
351: import {ok as assert} from 'devlop'
352: import isPlainObj from 'is-plain-obj'

Expected behavior

either

• extend gets a default export
• we drop the extend library 🙈

See: https://rollupjs.org/troubleshooting/#error-name-is-not-exported-by-module

Runtime

node 24

Package manager

rollup 4.x

Operating system

doesn't matter

Build and bundle tools

Rollup

[NullVoxPopuli]

Actually there is a work around.

This rollup plugin https://www.npmjs.com/package/@rollup/plugin-commonjs does some compat stuff to work-around the problem if I bundle unified in to my library.

it would not solve the problem if I just declare unified as a dependencies entry

[ChristianMurphy]

If vite doesn't support this, its a bug in vite #153 (comment)

They've fixed it before, the only remaining edge cases would be pre-bundling are you doing that? vitejs/vite#3024 (comment)

extend gets a default export

See justmoon/node-extend#57

[github-actions]

Hi! This was closed. Team: If this was fixed, please add phase/solved. Otherwise, please add one of the no/* labels.

[github-actions]

Hi! Thanks for taking the time to contribute!

Because we treat issues as our backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn’t an exact duplicate but is closely related.

Thanks,
— bb

[github-actions]

Hi team! It seems this post is a duplicate, but hasn’t been marked as such. Please post a comment w/ Duplicate of #123(no final .) to do so. See GH docs for more info.

Thanks,
— bb

[ChristianMurphy]

Duplicate of #153

[NullVoxPopuli]

If vite doesn't support this, its a bug in vite #153 (comment)

Vite is not the tool I'm using tho.

are you doing that? vitejs/vite#3024 (comment)

as a library author, this is not feasible, as the consumers of my library may or may not be using vite, I can't know.

unified 11.0.5
└── extend 3.0.2 # this is the latest version

See justmoon/node-extend#57

Can we remove this line:

unified/lib/index.js

Line 1160 in 45d8fa5

primary = extend(true, currentPrimary, primary)

-- we could write an internal much smaller deep clone using Object.assign