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.
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
Add warning package #19317
Add warning package #19317
Changes from 9 commits
234e5b6
6649664
e3ba9d7
a2732ec
93eddbb
e357a17
ff25618
d42843e
be1f921
0765740
aa2d200
b045842
47cce9f
bb8209a
d046ef6
25dfd7f
44cdafe
ac20da3
f0bf765
b389b34
1724346
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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'm very glad you are thinking about dead code elimination with this pull request.
One concern I have about this specific implementation is that it makes a few assumptions about the runtime and build environments that I'm not sure we should be comfortable to make:
process.env.NODE_ENV
global is assigned, or that the generated code is only able to run in Node.js (and not in a browser, whereprocess.env
does not exist)If either of these are not met, then either the code will not in-fact be removed, or at worst it can cause errors in the runtime environment (e.g. trying to access property
NODE_ENV
of an undefinedprocess.env
in a browser).What I'd wonder is: Is there any reason we'd not want to just remove the call expression here and now based on what
process.env
evaluates to in the Babel transform? I guess I can see how we might not want that though if, for example, we want the warnings to be logged in projects which depend on our packages (where the published packages would be built in a "production" environment?).It all looks very similar to Facebook's internal
invariant
utility. I guess this is intentional? How do they handle it? Or, since those are used in internal projects, are they fine to make those assumptions about the runtime/build environment?Alternatively, we could do some combination of:
process
global exists before evaluating ittypeof process !== 'undefined' && typeof process.env !== 'undefined' && process.env.NODE_ENV
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.
@aduth I think I assumed we were handling
process.env.NODE_ENV
somehow because it's being used in other parts of the code base. For example:gutenberg/packages/components/src/tooltip/index.js
Lines 147 to 150 in 8719578
Looking at the code generated in the
build
/build-module
folders, that check remains there. I'm confused now! How does it work? Where can I find the code responsible for building the code for the browser?I expect some warnings like this:
If we remove the warning call from the code we ship to npm, then people won't see that (when using
@wordpress/components
, for example).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.
Facebook uses
__DEV__
:https://github.com/facebook/react/blob/3c54df0914f02fed146faa519a5a899d0e3af32e/packages/shared/consoleWithStackDev.js#L31
I guess the benefit is that it fallbacks to
undefined
and therefore doesn't call the guarded code. You can still benefit from dead code elimination by teaching webpack to convert it totrue
orfalse
.I don't know what's the best way to move forward, but I'm sharing how I see the approach FB took.
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.
In this case, I assume something must still be assigning
__DEV__
value, as otherwise the reference to an undeclared variable would throw an error:Revisiting my earlier comment, I'm actually not sure we're doing anything wrong here with how we reference
process.env.NODE_ENV
. I think it could be fair to say that if we're distributing this as a Node package, it may be more-or-less assumed that it be evaluated as in a Node context where theprocess
global is defined. I do worry that in a standalone context, there is a chance that this might not be substituted correctly when building for a browser target. At least in the case of Webpack, this is handled automatically as far as I can tell (seemode
,DefinePlugin
).A safe option might just be to test its presence before evaluating it (
typeof process !== 'undefined'
).With regards to other existing code in the codebase, I think one of two of the following might be the case:
For something like a
warning
package, it seemed highly likely we'd want to promote that this be used separate from Gutenberg and its build, hence the original concern.