-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
feat: allow to set web
/webworker
and node
environments
#18336
Conversation
For maintainers only:
|
() => /** @type {boolean | undefined} */ (tp && tp.bigIntLiteral) | ||
() => | ||
tp && | ||
optimistic(/** @type {boolean | undefined} */ (tp && tp.bigIntLiteral)) |
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.
We use the same for const
/forOf
/etc, so let's use the same here when no targets avaliable
need to think about this carefully.. idea of |
something like class Target. Instance of which will be assignment to compiler and then use something like |
@vankop Yeah, I thought about it, but we have |
@alexander-akait |
wdyt about this design @alexander-akait #18378 ? |
@vankop Yeah, looks good, I put a comment about loader context there |
Fixed |
What kind of change does this PR introduce?
Feature. Why we need to expose them:
web
target (but not webworker)enviroment
isnode
Why we can't use just
target
? Because developer can havetarget: "browserslist"
and to undestan the rightenviroment
we need to do load and resolve it (webpack already does it, so no need to duplicate it)Also there is a fix for
bigIntLiteral
, because we use theoptimistic
strategy when nothing avaliable for ECMA featuresDid you add tests for your changes?
Yes
Does this PR introduce a breaking change?
NO
What needs to be documented once your changes are merged?
New options
/cc @vankop