[bug]: one .d.ts serves both import and require outputs, so types masquerade as CJS for ESM consumers

Aperta
  • Qualcosa non va?
#241 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 6 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript, vite
Ambito
build-system, cli, tooling

Direzione di ricerca

Start with the vite-plugin-dts setup in build, then trace the default exports map written by init and the export checks in verify. Reproduce the issue with src/__tests__/fixtures/typescript-plugin and @arethetypeswrong/cli. Done means import and require conditions point to declarations in matching formats, and verification accepts the nested exports map.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What version of @strapi/sdk-plugin are you using?
  • @strapi/sdk-plugin 6.1.1 (also current main)
  • Node.js 24.21.0
  • TypeScript 5.x (checked with @arethetypeswrong/cli 0.18.5)
What's Wrong?

strapi-plugin build emits a single declaration file per bundle (dist/admin/src/index.d.ts, dist/server/src/index.d.ts), and the exports map generated by init points one top-level types condition at it for both the import (index.mjs) and require (index.js) outputs:

"./strapi-server": {
  "types": "./dist/server/src/index.d.ts",
  "source": "./server/src/index.ts",
  "import": "./dist/server/index.mjs",
  "require": "./dist/server/index.js",
  "default": "./dist/server/index.js"
}

TypeScript decides a .d.ts file's module format from the nearest package.json#type. In a "type": "commonjs" plugin (what init generates), that one .d.ts is read as CommonJS, so ESM consumers resolving under node16/nodenext get CommonJS types for an ES module. Are the Types Wrong reports this as 🎭 Masquerading as CJS for both ./strapi-admin and ./strapi-server.

In a "type": "module" plugin the same layout flips the problem: the .d.ts is read as ESM, so require consumers would get ESM types (Masquerading as ESM).

To Reproduce

Using the repo's own typescript-plugin test fixture:

  1. Copy src/__tests__/fixtures/typescript-plugin somewhere outside the repo.
  2. Build it with strapi-plugin build.
  3. Run npx @arethetypeswrong/cli --pack . in that directory.

Output:

                                     │ node10               │ node16 (from CJS) │ node16 (from ESM)      │ bundler
"@strapi/plugin-test/strapi-admin"   │ 💀 Resolution failed │ 🟢 (CJS)          │ 🎭 Masquerading as CJS │ 🟢
"@strapi/plugin-test/strapi-server"  │ 💀 Resolution failed │ 🟢 (CJS)          │ 🎭 Masquerading as CJS │ 🟢

(The node10 failure is expected for an exports-only package with no top-level main/types. This issue is about the node16 (from ESM) column.)

Expected Behaviour

Each output format gets declarations TypeScript reads in the matching format, and the exports map points to them per condition, for example:

"./strapi-server": {
  "source": "./server/src/index.ts",
  "import": {
    "types": "./dist/server/src/index.d.mts",
    "default": "./dist/server/index.mjs"
  },
  "require": {
    "types": "./dist/server/src/index.d.ts",
    "default": "./dist/server/index.js"
  },
  "default": "./dist/server/index.js"
}

i.e. .d.mts next to ESM output and .d.ts / .d.cts next to CommonJS output, chosen to match package.json#type. ESM-only or CJS-only plugins keep a single declaration file in the right format.

This would touch:

  • the vite-plugin-dts setup in build (emit declarations per format),
  • the default exports map written by init,
  • verify's export checks, which currently expect a top-level types first and flat string import / require values.
Lingua principale
TypeScript
Stelle
24
Fork
13
Merge medio
5g 3h
PR unite (30g)
5

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di strapi/sdk-plugin

Tutte le issue di strapi/sdk-plugin

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.