2022-08-16 18:37:16 +03: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-25 01:03:43 +03:00
|
|
|
"declarationMap": false,
|
2022-08-16 18:37:16 +03: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-25 01:03:43 +03:00
|
|
|
"inlineSources": true,
|
2022-08-16 18:37:16 +03:00
|
|
|
"strict": true,
|
|
|
|
|
"strictNullChecks": false,
|
2022-11-30 03:15:24 +03:00
|
|
|
"target": "es2020",
|
|
|
|
|
"types": ["lit", "jasmine"]
|
2023-05-11 00:04:20 +03:00
|
|
|
},
|
|
|
|
|
"exclude": [
|
2023-05-24 01:25:07 +03:00
|
|
|
"catalog",
|
2023-09-20 07:05:08 +03:00
|
|
|
"**/demo",
|
|
|
|
|
"scripts/"
|
2023-05-11 00:04:20 +03:00
|
|
|
]
|
2022-08-16 18:37:16 +03:00
|
|
|
}
|
