package.json declares only browser/unpkg/jsdelivr (IIFE dist) and types. There is no main, module, or exports field, and no type: "module", so import ... from '@no-js-dev/nojs' does not resolve for Node/bundler consumers.
Since v1.21.0 the package exposes a compiler-support API surface (parseExpression, parseStatements, segmentPipes, re-exported from src/index.js) intended for library consumption by @no-js-dev/server. Today it is only reachable via a direct path import (@no-js-dev/nojs/src/index.js), which additionally requires the consumer to treat the file as ESM even though the package is typed as CJS.
Fixing this properly means either adding type: "module" (and migrating build.js / jest / dev-server scripts accordingly) or emitting a dedicated dist/esm build and pointing an exports map at it. A broken advertised entry would be worse than none, so this deserves its own change rather than a release-train tweak.
Ref: docs/md/plugins.md "Compiler Support — Parser Exports (ADR-024)".
package.jsondeclares onlybrowser/unpkg/jsdelivr(IIFE dist) andtypes. There is nomain,module, orexportsfield, and notype: "module", soimport ... from '@no-js-dev/nojs'does not resolve for Node/bundler consumers.Since v1.21.0 the package exposes a compiler-support API surface (
parseExpression,parseStatements,segmentPipes, re-exported fromsrc/index.js) intended for library consumption by@no-js-dev/server. Today it is only reachable via a direct path import (@no-js-dev/nojs/src/index.js), which additionally requires the consumer to treat the file as ESM even though the package is typed as CJS.Fixing this properly means either adding
type: "module"(and migrating build.js / jest / dev-server scripts accordingly) or emitting a dedicateddist/esmbuild and pointing anexportsmap at it. A broken advertised entry would be worse than none, so this deserves its own change rather than a release-train tweak.Ref: docs/md/plugins.md "Compiler Support — Parser Exports (ADR-024)".