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

Abierto
  • ¿Algo no está bien?
#241 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 6 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript, vite
Área
build-system, cli, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
24
Forks
13
Merge medio
5 d 3 h
PR fusionados (30 d)
5

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de strapi/sdk-plugin

Todos los issues de strapi/sdk-plugin

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.