chore: fully type check packages/*/src files #117
Conversation
There was a problem hiding this comment.
[Question] I ended up writing this because I wanted to add a mention of how to type-check, and didn't know where to put it... is this the right place for rewrite contributing docs?
There was a problem hiding this comment.
I think it's fine for now. I'm always torn between CONTRIBUTING.md and README.md. I think it's more important that the information exists somewhere rather than worrying about exactly where at this point.
| @@ -27,6 +28,7 @@ | |||
| "!(*.{js,ts})": "prettier --write --ignore-unknown" | |||
| }, | |||
| "devDependencies": { | |||
| "@types/mocha": "^10.0.7", | |||
There was a problem hiding this comment.
[Explanation] This isn't strictly necessary with "noImplicitAny": false. But it's just good to have types for dependencies in general.
| * Creates an array of directories to be built in order to sastify dependencies. | ||
| * @param {Map<string,{name:string,dir:string,dependencies:Set<string>}} dependencies The | ||
| * Creates an array of directories to be built in order to satisfy dependencies. | ||
| * @param {Map<string,{name:string,dir:string,dependencies:Set<string>}>} dependencies The |
There was a problem hiding this comment.
[Fix] Typo: missing > closing out Map.
tsconfig.base.json
Outdated
| // TODO: Over time, enable these strict options | ||
| "noImplicitAny": false, | ||
| "strictNullChecks": false, | ||
| "useUnknownInCatchVariables": false |
There was a problem hiding this comment.
[Explanation] strict is generally a best practice, and has flags added to it over time. For anything that can't be added yet, the common practice is to disable them specifically with a TODO comment. Kind of like enabling a recommended preset in an ESLint config, with rules overrides.
I know there was mention of not wanting some or all of these - is here a good place to discuss?
There was a problem hiding this comment.
I think strict vs. not should be opened up as a separate discussion.
| ### Linting | ||
|
|
||
| ESLint is linted using ESLint. | ||
| [Building](#building) the project must be done before it can lint itself. |
There was a problem hiding this comment.
Did you find this to be true? Linting generally happens on source files, so not sure why building would be required first.
There was a problem hiding this comment.
Yes, it has a dependency on its own files right now:
$ npm run lint
> [email protected] lint
> eslint .
Oops! Something went wrong! :(
ESLint: 9.9.1
Error: Cannot find module '/Users/josh/repos/rewrite/node_modules/@eslint/config-array/dist/cjs/index.cjs'
at createEsmNotFoundErr (node:internal/modules/cjs/loader:1256:15)
at finalizeEsmResolution (node:internal/modules/cjs/loader:1244:15)
at resolveExports (node:internal/modules/cjs/loader:628:14)
at Module._findPath (node:internal/modules/cjs/loader:718:31)
at Module._resolveFilename (node:internal/modules/cjs/loader:1205:27)
at Module._load (node:internal/modules/cjs/loader:1045:27)
at TracingChannel.traceSync (node:diagnostics_channel:315:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:215:24)
at Module.require (node:internal/modules/cjs/loader:1304:12)
at require (node:internal/modules/helpers:123:16)
Running a build fixes that:
$ npm run build
# ... build output
$ npm run lint
> [email protected] lint
> eslint .
$ |
Co-authored-by: Nicholas C. Zakas <[email protected]>
| @@ -8,6 +8,7 @@ | |||
| "build": "node scripts/build.js", | |||
| "build:readme": "node tools/update-readme.js", | |||
| "lint": "eslint .", | |||
| "tsc": "tsc", | |||
There was a problem hiding this comment.
We have some guidelines around script names, so I'd suggest this:
| "tsc": "tsc", | |
| "test:types": "tsc", |
| @@ -123,7 +122,8 @@ export class ConfigCommentParser { | |||
| parseJSONLikeConfig(string) { | |||
| // Parses a JSON-like comment by the same way as parsing CLI option. | |||
| try { | |||
| const items = levn.parse("Object", string) || {}; | |||
| const items = | |||
| /** @type {RulesConfig} */ (levn.parse("Object", string)) || {}; | |||
There was a problem hiding this comment.
Should the parens enclose the entire expression?
| /** @type {RulesConfig} */ (levn.parse("Object", string)) || {}; | |
| /** @type {RulesConfig} */ (levn.parse("Object", string) || {}); |
Prerequisites checklist
What is the purpose of this pull request?
Creates a root-level
tsconfig.jsonthat can type check all project files, along with aci.ymlstep to do so in CI.What changes did you make? (Give an overview)
This PR includes two common TypeScript practices for monorepos:
tsconfig.base.json: to unify & share the common TSConfig settings used by all projectstsconfig.json: so editors have that includes all filesThat root-level
tsconfig.jsonis necessary for typed linting with the recommended typescript-eslint project service, as noted by @snitin315 and myself as a followup in #90 -> #90 (comment).Also fixes a few type errors here and there. I'm posting comments in the PR.
Notably, this PR does not set up project references. Doing so requires touching files on disk, which I'm not confident enough in this repo to do on my own unprompted. Instead, the root-level
tsconfig.jsonhasnoEmit: trueso it's purely used for type checking.Related Issues
Followup to #90, which is a PR. Would the team like me to file more granular issues? I wasn't sure how much the team wants some or all of this change. My intent is to continue enabling strict TypeScript flags after this, unless directed otherwise.
Is there anything you'd like reviewers to focus on?
I'm applying the practices I see as common + good in TypeScript-land, but am not totally sure I interpreted the existing repo setup right. Very much seeking to understand. 🙂