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

オープン
#241 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 6 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript, vite

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
TypeScript
スター
24
フォーク
13
平均マージ
5日 3時間
マージ済み PR(30日)
5

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

strapi/sdk-plugin のほかの issue

strapi/sdk-plugin の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。