2022-08-16 08:37:16 -07:00
|
|
|
{
|
|
|
|
|
"compilerOptions": {
|
|
|
|
|
"allowUnreachableCode": false,
|
|
|
|
|
"baseUrl": ".",
|
|
|
|
|
"declaration": true,
|
chore: Don't publish .ts or testing files
Before this change, we publish .ts source files to the same directory as the .js/.d.ts files to npm.
That means when a consumer imports a @material/web module with TypeScript, TypeScript prefers the .ts file over the .d.ts file when to load that module's types.
That in turn means the consumer's TypeScript type-checks the entire @material/web .ts file, including its private implementation details (private fields, etc.). If the consumer's tsconfig.json is configured more strictly than @material/web's was (e.g. if noUnusedParameters is true), or if some additional ambient types are loaded (e.g. @types/node is installed, which changes the signature of setTimeout), they would get a compile error.
This change stops publishing .ts files to npm to solve that problem for consumers.
This also includes some related changes:
- Sets inlineSources to true. This puts the .ts file contents directly inside the .js.map file, instead of linking to the .ts path. Otherwise sourcemaps would not work.
- Sets declarationMap to false. This removes the .d.ts.map files, which are not useful without the .ts paths, because there is no equivalent to inlineSources for declarationMap (see https://github.com/microsoft/TypeScript/issues/38966).
- Replaces .npmignore blocklist with package.json files allowlist (which I find to be a bit safer), and adds new omissions for testing files, which don't need to be published.
Note that this doesn't solve the problem when using "npm link" for local cross-package development, because in that case the .ts files will still be present. So a better solution to this problem would be to have a separate src/ directory for .ts source files. That will require a Copybara transform to move the files. We can discuss this separately and do it as a followup if agreed.
PiperOrigin-RevId: 469833263
2022-08-24 15:03:43 -07:00
|
|
|
"declarationMap": false,
|
2022-08-16 08:37:16 -07:00
|
|
|
"downlevelIteration": true,
|
|
|
|
|
"experimentalDecorators": true,
|
|
|
|
|
"importHelpers": true,
|
|
|
|
|
"module": "es2015",
|
|
|
|
|
"moduleResolution": "node",
|
|
|
|
|
"noFallthroughCasesInSwitch": true,
|
|
|
|
|
"noImplicitAny": true,
|
|
|
|
|
"noImplicitOverride": true,
|
|
|
|
|
"noImplicitReturns": true,
|
|
|
|
|
"noImplicitThis": true,
|
|
|
|
|
"noPropertyAccessFromIndexSignature": true,
|
|
|
|
|
"noUnusedLocals": true,
|
|
|
|
|
"paths": {
|
|
|
|
|
"@material/web/*": ["./*"]
|
|
|
|
|
},
|
|
|
|
|
"sourceMap": true,
|
chore: Don't publish .ts or testing files
Before this change, we publish .ts source files to the same directory as the .js/.d.ts files to npm.
That means when a consumer imports a @material/web module with TypeScript, TypeScript prefers the .ts file over the .d.ts file when to load that module's types.
That in turn means the consumer's TypeScript type-checks the entire @material/web .ts file, including its private implementation details (private fields, etc.). If the consumer's tsconfig.json is configured more strictly than @material/web's was (e.g. if noUnusedParameters is true), or if some additional ambient types are loaded (e.g. @types/node is installed, which changes the signature of setTimeout), they would get a compile error.
This change stops publishing .ts files to npm to solve that problem for consumers.
This also includes some related changes:
- Sets inlineSources to true. This puts the .ts file contents directly inside the .js.map file, instead of linking to the .ts path. Otherwise sourcemaps would not work.
- Sets declarationMap to false. This removes the .d.ts.map files, which are not useful without the .ts paths, because there is no equivalent to inlineSources for declarationMap (see https://github.com/microsoft/TypeScript/issues/38966).
- Replaces .npmignore blocklist with package.json files allowlist (which I find to be a bit safer), and adds new omissions for testing files, which don't need to be published.
Note that this doesn't solve the problem when using "npm link" for local cross-package development, because in that case the .ts files will still be present. So a better solution to this problem would be to have a separate src/ directory for .ts source files. That will require a Copybara transform to move the files. We can discuss this separately and do it as a followup if agreed.
PiperOrigin-RevId: 469833263
2022-08-24 15:03:43 -07:00
|
|
|
"inlineSources": true,
|
2022-08-16 08:37:16 -07:00
|
|
|
"strict": true,
|
|
|
|
|
"strictNullChecks": false,
|
2024-07-02 15:21:31 -07:00
|
|
|
"target": "es2021",
|
2022-11-29 16:15:24 -08:00
|
|
|
"types": ["lit", "jasmine"]
|
2023-05-10 14:04:20 -07:00
|
|
|
},
|
|
|
|
|
"exclude": [
|
2023-05-23 15:25:07 -07:00
|
|
|
"catalog",
|
2023-09-19 21:05:08 -07:00
|
|
|
"**/demo",
|
|
|
|
|
"scripts/"
|
2023-05-10 14:04:20 -07:00
|
|
|
]
|
2022-08-16 08:37:16 -07:00
|
|
|
}
|
