diff --git a/.changeset/eight-turkeys-crash.md b/.changeset/eight-turkeys-crash.md new file mode 100644 index 0000000..d2ee6a6 --- /dev/null +++ b/.changeset/eight-turkeys-crash.md @@ -0,0 +1,6 @@ +--- +"@arethetypeswrong/core": patch +"@arethetypeswrong/cli": patch +--- + +Fix typo in MissingExportEquals message diff --git a/docs/problems/MissingExportEquals.md b/docs/problems/MissingExportEquals.md index 6663e68..02b4bb2 100644 --- a/docs/problems/MissingExportEquals.md +++ b/docs/problems/MissingExportEquals.md @@ -1,6 +1,6 @@ # ❓ Missing `export =` -The JavaScript appears to set both `module.exports` and `module.exports.default` for improved compatibility, but the types only reflect the latter (by using `export default`). This will cause TypeScript under the `node16` module mode to think an extra `.default` property access is required, which will work at runtime but is not necessary. These types `export =` an object with a `default` property instead of using `export default`. +The JavaScript appears to set both `module.exports` and `module.exports.default` for improved compatibility, but the types only reflect the latter (by using `export default`). This will cause TypeScript under the `node16` module mode to think an extra `.default` property access is required, which will work at runtime but is not necessary. These types should `export =` an object with a `default` property instead of using `export default`. ## Explanation diff --git a/packages/cli/test/snapshots/@vitejs__plugin-react@3.1.0.tgz.md b/packages/cli/test/snapshots/@vitejs__plugin-react@3.1.0.tgz.md index 24d30c3..189c7ce 100644 --- a/packages/cli/test/snapshots/@vitejs__plugin-react@3.1.0.tgz.md +++ b/packages/cli/test/snapshots/@vitejs__plugin-react@3.1.0.tgz.md @@ -6,7 +6,7 @@ $ attw @vitejs__plugin-react@3.1.0.tgz -f table-flipped @vitejs/plugin-react v3.1.0 -❓ The JavaScript appears to set both module.exports and module.exports.default for improved compatibility, but the types only reflect the latter (by using export default). This will cause TypeScript under the node16 module mode to think an extra .default property access is required, which will work at runtime but is not necessary. These types export = an object with a default property instead of using export default. https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/MissingExportEquals.md +❓ The JavaScript appears to set both module.exports and module.exports.default for improved compatibility, but the types only reflect the latter (by using export default). This will cause TypeScript under the node16 module mode to think an extra .default property access is required, which will work at runtime but is not necessary. These types should export = an object with a default property instead of using export default. https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/MissingExportEquals.md 🎭 Import resolved to a CommonJS type declaration file, but an ESM JavaScript file. https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/FalseCJS.md diff --git a/packages/cli/test/snapshots/ajv@8.12.0.tgz.md b/packages/cli/test/snapshots/ajv@8.12.0.tgz.md index fb2e0bd..c513954 100644 --- a/packages/cli/test/snapshots/ajv@8.12.0.tgz.md +++ b/packages/cli/test/snapshots/ajv@8.12.0.tgz.md @@ -11,7 +11,7 @@ Build tools: - rollup@^2.44.0 - @rollup/plugin-typescript@^10.0.1 -❓ The JavaScript appears to set both module.exports and module.exports.default for improved compatibility, but the types only reflect the latter (by using export default). This will cause TypeScript under the node16 module mode to think an extra .default property access is required, which will work at runtime but is not necessary. These types export = an object with a default property instead of using export default. https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/MissingExportEquals.md +❓ The JavaScript appears to set both module.exports and module.exports.default for improved compatibility, but the types only reflect the latter (by using export default). This will cause TypeScript under the node16 module mode to think an extra .default property access is required, which will work at runtime but is not necessary. These types should export = an object with a default property instead of using export default. https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/MissingExportEquals.md ┌───────┬───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┐ diff --git a/packages/cli/test/snapshots/postcss@8.4.21.tgz.md b/packages/cli/test/snapshots/postcss@8.4.21.tgz.md index ae02aaf..d80a6a5 100644 --- a/packages/cli/test/snapshots/postcss@8.4.21.tgz.md +++ b/packages/cli/test/snapshots/postcss@8.4.21.tgz.md @@ -6,7 +6,7 @@ $ attw postcss@8.4.21.tgz -f table-flipped postcss v8.4.21 -❓ The JavaScript appears to set both module.exports and module.exports.default for improved compatibility, but the types only reflect the latter (by using export default). This will cause TypeScript under the node16 module mode to think an extra .default property access is required, which will work at runtime but is not necessary. These types export = an object with a default property instead of using export default. https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/MissingExportEquals.md +❓ The JavaScript appears to set both module.exports and module.exports.default for improved compatibility, but the types only reflect the latter (by using export default). This will cause TypeScript under the node16 module mode to think an extra .default property access is required, which will work at runtime but is not necessary. These types should export = an object with a default property instead of using export default. https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/MissingExportEquals.md 🐛 Import resolved to types through a conditional package.json export, but only after failing to resolve through an earlier condition. This behavior is a TypeScript bug (https://github.com/microsoft/TypeScript/issues/50762). It may misrepresent the runtime behavior of this import and should not be relied upon. https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/FallbackCondition.md diff --git a/packages/core/src/problems.ts b/packages/core/src/problems.ts index 9f35878..62fd3e7 100644 --- a/packages/core/src/problems.ts +++ b/packages/core/src/problems.ts @@ -90,7 +90,7 @@ export const problemKindInfo: Record = { title: "Types are missing an `export =`", shortDescription: "Missing `export =`", description: - "The JavaScript appears to set both `module.exports` and `module.exports.default` for improved compatibility, but the types only reflect the latter (by using `export default`). This will cause TypeScript under the `node16` module mode to think an extra `.default` property access is required, which will work at runtime but is not necessary. These types `export =` an object with a `default` property instead of using `export default`.", + "The JavaScript appears to set both `module.exports` and `module.exports.default` for improved compatibility, but the types only reflect the latter (by using `export default`). This will cause TypeScript under the `node16` module mode to think an extra `.default` property access is required, which will work at runtime but is not necessary. These types should `export =` an object with a `default` property instead of using `export default`.", docsUrl: "https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/MissingExportEquals.md", },