What happened:
@yorkie-js/sdk, @yorkie-js/react and @yorkie-js/prosemirror each build both an ES module (*.es.js) and a UMD bundle, and publish both to npm — but the published package.json points main at the UMD build only. There is no exports map and no module field, so the package's ESM entry is never actually exposed.
As a result, when Node loads the package directly as ESM, the .js file main names is interpreted as CommonJS and named imports fail:
SyntaxError: Named export 'Document' not found. The requested module
'@yorkie-js/sdk' is a CommonJS module, which may not support all
module.exports as named exports.
The first line of Usage in the @yorkie-js/prosemirror README fails the same way in that environment:
import { YorkieProseMirrorBinding } from '@yorkie-js/prosemirror';
// SyntaxErrorWhat you expected to happen:
import { Document } from '@yorkie-js/sdk' should work under Node ESM, matching what the shipped .d.ts declares.
How to reproduce it (as minimally and precisely as possible):
A default npm init -y project and a single .mjs file is enough. No "type": "module" setting is required.
npm init -y
npm i @yorkie-js/sdk@0.7.18
echo "import { Document } from '@yorkie-js/sdk';" > repro.mjs
node repro.mjsResult:
SyntaxError: Named export 'Document' not found...
A more realistic path is Vite SSR. Dependencies are externalized by default, so the import survives into the build output and Node loads it directly when the SSR output runs, producing the same error. The browser bundle is fine while server-side rendering crashes.
Anything else we need to know?:
The shipped .d.ts declares the named exports correctly, so type checking passes even in a "type": "module" project with moduleResolution: nodenext — the error only appears when the compiled JS is executed.
This does not reproduce in ordinary browser builds where a bundler bundles the dependency
itself. Verified working with Vite, webpack 5 and esbuild.
It affects environments where Node loads the published package entry directly, such as:
- Node ESM —
.mjs/.mts files, or any project with "type": "module"
- entry points
node runs directly without a bundler — e.g. a Next.js custom server (node server.mts)
- SSR builds where the dependency is externalized — e.g. Vite SSR's default behaviour
- tests that run without bundling dependencies — e.g.
node --test
Environment:
- Operating system: Ubuntu 24.04.2 LTS (WSL2)
- Browser and version:
- Yorkie version (use
yorkie version):
- Yorkie JS SDK version: 0.7.18
What happened:
@yorkie-js/sdk,@yorkie-js/reactand@yorkie-js/prosemirroreach build both an ES module (*.es.js) and a UMD bundle, and publish both to npm — but the publishedpackage.jsonpointsmainat the UMD build only. There is noexportsmap and nomodulefield, so the package's ESM entry is never actually exposed.As a result, when Node loads the package directly as ESM, the
.jsfilemainnames is interpreted as CommonJS and named imports fail:The first line of Usage in the
@yorkie-js/prosemirrorREADME fails the same way in that environment:What you expected to happen:
import { Document } from '@yorkie-js/sdk'should work under Node ESM, matching what the shipped.d.tsdeclares.How to reproduce it (as minimally and precisely as possible):
A default
npm init -yproject and a single.mjsfile is enough. No"type": "module"setting is required.Result:
A more realistic path is Vite SSR. Dependencies are externalized by default, so the import survives into the build output and Node loads it directly when the SSR output runs, producing the same error. The browser bundle is fine while server-side rendering crashes.
Anything else we need to know?:
The shipped
.d.tsdeclares the named exports correctly, so type checking passes even in a"type": "module"project withmoduleResolution: nodenext— the error only appears when the compiled JS is executed.This does not reproduce in ordinary browser builds where a bundler bundles the dependency
itself. Verified working with Vite, webpack 5 and esbuild.
It affects environments where Node loads the published package entry directly, such as:
.mjs/.mtsfiles, or any project with"type": "module"noderuns directly without a bundler — e.g. a Next.js custom server (node server.mts)node --testEnvironment:
yorkie version):