@fedify/cli 2.1.2 and 2.0.9 fail at startup because @fedify/init publishes .mjs files but exports .js

[dahlia]

npx -y @fedify/cli@2.1.2 fails immediately, while 2.1.1 works.

The same regression appears on the 2.0 maintenance line: @fedify/cli@2.0.9 fails, while 2.0.8 works.

Reproduction

npx -y @fedify/cli@2.1.2 --help

Also reproducible with:

npx -y @fedify/cli@2.0.9 --help

Actual result

Node fails during module resolution:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '.../node_modules/@fedify/init/dist/mod.js'
imported from '.../node_modules/@fedify/cli/dist/init/mod.js'

Expected result

The CLI should start normally and print help output, as it does with:

npx -y @fedify/cli@2.1.1 --help
npx -y @fedify/cli@2.0.8 --help

Suspected cause

This looks like a packaging regression introduced in the releases that also contained the tsdown upgrade for fixing #651.

From the published packages:

• @fedify/init@2.1.2 and @fedify/init@2.0.9 contain dist/mod.mjs and dist/mod.d.mts
• but their package.json still points main / exports.import / types to ./dist/mod.js and ./dist/mod.d.ts

So @fedify/cli imports @fedify/init, Node resolves through @fedify/init's export map, and then fails because dist/mod.js does not actually exist in the published tarball.

That also explains why even fedify --help fails: the CLI imports its init module eagerly during startup.

Notes

The issue seems specific to the published npm artifacts, not to the CLI command logic itself.

The relevant version boundary is:

• working: @fedify/cli@2.1.1, @fedify/init@2.1.1
• broken: @fedify/cli@2.1.2, @fedify/init@2.1.2

and likewise:

• working: @fedify/cli@2.0.8, @fedify/init@2.0.8
• broken: @fedify/cli@2.0.9, @fedify/init@2.0.9