refactor(site): match v1 tsconfig; simplify tsconfig.test.json #426
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary (a1164f4)
Matched the
tsconfig.json
post migration to webpack with that of v1Details
allowJs
removed -> not needed after Next.jsnext-env.d.ts
from fileinclude
snoImplicitAny
removed -> this is set totrue
bystrict
and is really only meaningful when being selectively stricttrue
bystrict
and is really only meaningful when being selectively strictImpact of Changes
There is no observable impact (this is just a refactor), outside of readability and parity with v1.
Why re-order?
Sometimes using an arbitrary ordering means more scans (think like a O(N) search) to figure out what properties are configured. In the case of TS configuration, I think alphabetical makes sense because the configurations are usually small. In other cases, it's helpful to have logical groupings. In other words, this improvement is in theme of "at a glance behaviors": being able to retrieve information "at a glance" without having to search for it.
Summary (7e195d3)
Greatly simplified the
tsconfig.test.json
given the changes that happened to the basetsconfig.json
from the migration. Thetsconfig.test.json
was duplicating properties that were already configured in the basetsconfig.json
! The only real difference now is theincludes/excludes
, which makes sense given that one is meant for the test project, and not the other. Having parity on all other configurations means less "magic" between these scenarios.Impact of Changes