chore: fully type check packages/*/src files #117
Conversation
Co-authored-by: Nicholas C. Zakas <[email protected]>
|
@JoshuaKGoldberg are you still working on this? |
|
Yes! I'd been waiting on #118 to get resolved. Cleaning this up now. |
|
@JoshuaKGoldberg there's a merge conflict now. |
.github/workflows/ci.yml
Outdated
| - name: Install Packages | ||
| run: | | ||
| npm install | ||
| npm run build |
There was a problem hiding this comment.
doubt: why are we running a build? aren't we type checking on source?
There was a problem hiding this comment.
The types definition files aren't there until we build.
There was a problem hiding this comment.
If that is so, doesn't package build step fail when the type is wrong for the package? 🤔 do we need another tsc command to run separately on the main repo?
There was a problem hiding this comment.
Yeah that is true. That's a pain I've just dealt with in other repos. In theory we could do a strategy like || 0 to ignore any failures.
There was a problem hiding this comment.
just to re iterate, my doubt was why we'd need to run build command and test:types on source files?
- the build process itself has a in-built
tsccheck? if the build fails thentscis also expected to fail? - we cannot have a
tsccheck separately because its dependent onbuild(which in itself has atsccheck?)
now the question resolves to do we have any other ts files apart from the ts files that are built in the repo? if yes then its better to have a tsc for fallback
(sorry for the confusion 😅)
There was a problem hiding this comment.
That's a good point. I hadn't noticed that test:types just runs tsc...for some reason I had it in my head that there was something else running there.
So yes, npm run build actually runs tsc, so we don't need something separate running tsc
There was a problem hiding this comment.
Just clarifying - is there a request for changes?
There was a problem hiding this comment.
Yes, there's no need to run tsc separately because that's already happening via npm run build.
There was a problem hiding this comment.
Ah got it. Thanks, I see now - sorry for giving you the runaround harish-sethuraman.
|
@JoshuaKGoldberg just a reminder that there are some comments for you to address in this PR. There's also a merge conflict. |
|
👍 on the merge conflict, fixed. I'm not clear on what else I need to do - asked inline. Thanks for the ping. |
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. 🙂