-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Update Preconstruct and use import conditions #3198
Conversation
🦋 Changeset detectedLatest commit: 55cd353 The changes in this PR will be included in the next version bump. This PR includes changesets to release 10 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
"exports": { | ||
"envConditions": [ | ||
"browser" | ||
] | ||
} |
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.
some packages had browser
conditions but I didn't keep them because, from what I can tell, they were unused. I only kept them when I could recognize them as being used
packages/styled/package.json
Outdated
"#is-browser": { | ||
"worker": "./src/conditions/false.js", | ||
"browser": "./src/conditions/true.js", | ||
"default": "./src/conditions/false.js" | ||
} |
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 is an important question: do we assume that default
means node
? or do we introduce a new node
entry and make default
contain an actual runtime check?
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.
Yeah, the default bundle should definitely contain the runtime check and like we could have worker
and node
point to just false, idk if it's worth it since the server-side bundle size consideration is nowhere near as big as client-side and maybe this wouldn't actually be a problem but you could e.g. use JSDOM in Node for tests in which case you'd want isBrowser
to be true
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 kinda feel like probably JSDOM users should use a jsdom condition or something but that's definitely not popular so ye, let's not add a node condition right now
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.
Btw. jest-environment-jsdom
is already preconfigured with the browser condition (in new Jest versions that is). So isBrowser
would already be true
in that context
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
|
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'd probably prefer if we ran all the tests in all environments by default and just had exceptions for the ones that only run in prod vs dev rather than running things only with the development
condition by default but this is probably fine
I agree but i just didnt have the energy to go through lots of tests and make this more explicit. A lot of tests assume the dev env atm so a lot of them would have to be annotated explicitly. It would be cool to explore changing this latwr on… if anybody finds the time to do so 😅 |
No description provided.