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

Open
  • Is something wrong?
#241 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 6 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript, vite
Domain
build-system, cli, tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
TypeScript
Stars
24
Forks
13
Avg merge
5d 3h
Merged PRs (30d)
5

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from strapi/sdk-plugin

All issues in strapi/sdk-plugin

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.