cismet / carma

carma monorepo: cids architecture for reactive mapping applications
0 stars 1 forks source link

Consolidate TSConfig, set strict by default. #81

Open mxfh opened 1 month ago

mxfh commented 1 month ago

I have created a small library that only contains the cesiumWidget and not the CesiumViewer + react for testing the tsconfig settings.

https://github.com/cismet/carma/blob/4137c7dc9e873cd895cdcc5c11241520eab8121c/libraries/mapping/engines/cesium-widget/tsconfig.json#L18

https://github.com/cismet/carma/blob/dev/tsconfig.base.json

Current local state of my tsconfig.base:

...
    "module": "preserve",
 // ^ also implies:
 // "moduleResolution": "bundler",
 // "esModuleInterop": true,
 // "resolveJsonModule": true,
 //  see links below
    "rootDir": ".",
    "sourceMap": true, // can maybe be removed?
    "declaration": false, // actually done by vite-dts
    "experimentalDecorators": true, // also not relevant fo noemit
    "noImplicitAny": false, // should not be here
    "importHelpers": true, // also a vite thing? then tslib could also be removed
    "target": "es2022",
    "lib": ["es2022", "dom"],
    "skipLibCheck": true, // noemit, not relevant 
    "baseUrl": ".",
    "noEmit": true, // transpilation done by vite
  ...

docs module release notes ts 5.4 module:preserve

in general I would like the settings to be

"strict": true
“verbatimModuleSyntax”: true,

by default and for new code and existing codebase opts out of those setting by overriding them when extending the base.

“verbatimModuleSyntax”: false, "noImplicitAny": false,

docs: verbatimModuleSyntax The project tsconfigs extending tsconfig.base

then it's possible to bring each project flag closer the stricter baseline by changing/removing the flag and changing code to adhere stricter style by a one-flag-one-commit-base.

the tsconfig.json that extend tsconfig.base.json then should only consist of those overrides and should have no other compile options besides those overriding strictness, the types or paths.

In general it seems a bit hard to follow what option imply others. like.

these all add a set of other options that should be noted somewhere, so changes to base and extending don't override or conflict those accidentally.

The other big topic is removing emit related options that are not observed by the bundler that does the actual transpiling in this case vite, dts-plugins etc will make new issue for those.

mxfh commented 1 month ago

"importHelpers" seem also pointless https://github.com/evanw/esbuild/issues/1230 and tslib can then be removed from deps