-
Notifications
You must be signed in to change notification settings - Fork 798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(snc): fix two snc errors related to .typesDir
#4815
Conversation
|
Path | Error Count |
---|---|
src/dev-server/index.ts | 37 |
src/mock-doc/serialize-node.ts | 36 |
src/dev-server/server-process.ts | 32 |
src/compiler/build/build-stats.ts | 27 |
src/compiler/output-targets/dist-lazy/generate-lazy-module.ts | 25 |
src/compiler/style/test/optimize-css.spec.ts | 23 |
src/testing/puppeteer/puppeteer-element.ts | 23 |
src/compiler/prerender/prerender-main.ts | 22 |
src/runtime/vdom/vdom-render.ts | 20 |
src/runtime/client-hydrate.ts | 19 |
src/screenshot/connector-base.ts | 19 |
src/compiler/config/test/validate-paths.spec.ts | 16 |
src/dev-server/request-handler.ts | 15 |
src/compiler/prerender/prerender-optimize.ts | 14 |
src/compiler/sys/stencil-sys.ts | 14 |
src/compiler/transpile/transpile-module.ts | 14 |
src/runtime/vdom/vdom-annotations.ts | 14 |
src/sys/node/node-sys.ts | 14 |
src/compiler/build/build-finish.ts | 13 |
src/compiler/prerender/prerender-queue.ts | 13 |
Our most common errors
Typescript Error Code | Count |
---|---|
TS2345 | 424 |
TS2322 | 398 |
TS18048 | 310 |
TS18047 | 100 |
TS2722 | 38 |
TS2532 | 34 |
TS2531 | 23 |
TS2454 | 14 |
TS2352 | 13 |
TS2769 | 10 |
TS2790 | 10 |
TS2538 | 8 |
TS2344 | 5 |
TS2416 | 4 |
TS2493 | 3 |
TS18046 | 2 |
TS2684 | 1 |
TS2488 | 1 |
TS2430 | 1 |
Unused exports report
There are 12 unused exports on this PR. That's the same number of errors on main, so at least we're not creating new ones!
Unused exports
File | Line | Identifier |
---|---|---|
src/runtime/bootstrap-lazy.ts | 21 | setNonce |
src/screenshot/screenshot-fs.ts | 18 | readScreenshotData |
src/testing/testing-utils.ts | 198 | withSilentWarn |
src/utils/index.ts | 140 | CUSTOM |
src/compiler/app-core/app-data.ts | 25 | BUILD |
src/compiler/app-core/app-data.ts | 114 | Env |
src/compiler/app-core/app-data.ts | 116 | NAMESPACE |
src/compiler/fs-watch/fs-watch-rebuild.ts | 123 | updateCacheFromRebuild |
src/compiler/types/validate-primary-package-output-target.ts | 62 | satisfies |
src/compiler/types/validate-primary-package-output-target.ts | 62 | Record |
src/testing/puppeteer/puppeteer-declarations.ts | 485 | WaitForEventOptions |
src/compiler/sys/fetch/write-fetch-success.ts | 7 | writeFetchSuccessSync |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
two notes
|
||
const outputs: d.OutputTarget[] = []; | ||
|
||
for (const outputTarget of distOutputTargets) { | ||
const distOutputTarget = validateOutputTargetDist(config, outputTarget); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while I was in here I thought hey, this .reduce
call is kind of weird, let's just for ... of
instead
* @param outputTarget the output target of interest | ||
* @returns a properly-formatted path | ||
*/ | ||
export const getComponentsDtsTypesFilePath = (outputTarget: Required<d.OutputTargetDist> | d.OutputTargetDistTypes) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added the Required<>
wrapper here to make sure the .typesDir
is defined, and this is legit since getComponentsDtsTypesFilePath
is only called in the validate-dist
file above where the argument satisfies that type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one other question
a2686d4
to
d8c62ad
Compare
This code is very much in the same area as #4661 - would it be okay if we held off on this until I got to the bottom of that issue (est early next week)? |
@@ -41,7 +41,7 @@ describe('validateDistOutputTarget', () => { | |||
empty: false, | |||
isBrowserBuild: true, | |||
legacyLoaderFile: path.join(rootDir, 'my-dist', 'my-build', 'testing.js'), | |||
polyfills: true, | |||
polyfills: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes from undefined
to false
here make sense to me, but the value changes from true
to false
less so. Can you help me understand why this is happening?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment gives some context, basically I changed it to ensure that the value on the generated output targets matches what it set on the "dist"
output target (the logic was more confusing before, if .polyfills
was undefined
on the dist
output target then it would end up always being true
on the dist-lazy
one, which doesn't seem right?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah - I think that comment was marked outdated and I missed it. However, I'm not sure this is the behavior we want. I could be missing something here, so just to check my understanding, this is what I think was happening and what's happening now:
- In this PR, as a result of validating the dist output target invoked here, the value on the validated
OutputTargetDist
value could previously be set totrue
|false
|undefined
. However, now that can betrue | false
as of this change, and defaults tofalse
. - Previously, we checked if
polyfills
wasundefined
. If it was, we set this value totrue
.
Wouldn't this change the behavior of copying over some of our polyfills? Today, I believe folks are relying on the behavior of "if I didn't set polyfills
, copy them anyway" (for dist
). Or am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it seems like they should be in sync
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mm yeah it's a bit complicated, I guess previously we actually had three different states we treated, basically
dist.polyfills
istrue
, thendist-lazy
should be truedist.polyfills
isfalse
, thendist-lazy
should be falsedist.polyfills
isundefined
, thendist-lazy
should betrue
I think the issue is that right now the undefined
case isn't distinguished from the false
case, I'll make the logic here check the original output target instead of the validated one (return value of validateOutputTargetDist
)
d8c62ad
to
6d3142f
Compare
687f7af
to
8560c8c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some opinions, but LGTM
@@ -41,7 +41,7 @@ describe('validateDistOutputTarget', () => { | |||
empty: false, | |||
isBrowserBuild: true, | |||
legacyLoaderFile: path.join(rootDir, 'my-dist', 'my-build', 'testing.js'), | |||
polyfills: true, | |||
polyfills: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it seems like they should be in sync
8560c8c
to
f068ef7
Compare
Ugh, sorry @alicewriteswrongs - I thought I had submitted this like, last week 😭 It's a little lost in the GH UI, but #4815 (comment) is my review/question |
f068ef7
to
f575d30
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Lots of back-and-forth for 2 checks 😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last clarifying question!
It won't let me reply with a normal comment (idk how to use github apparently haha) so RE:
Making that change will actually change the behavior. If we use the Tried to clarify that behavior here: #4815 (comment) It's a bit weird for sure, but lmk if you think that should change or if that's not clear |
This fixes two snc errors related to the `.typesDir` property and then additionally does a small refactor in `validate-dist.ts`.
f575d30
to
ad3b5cd
Compare
Just fixing two SNC errors.
What is the current behavior?
GitHub Issue Number: N/A
What is the new behavior?
Just dropping some SNC errors!
Does this introduce a breaking change?
Testing
This shouldn't break anything since I don't think the runtime behavior of anything will really be affected. Unit tests and whatnot should all be passing.
Other information