-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
build-system: consolidate all build time constants #34327
Conversation
1923485
to
bd1e3f9
Compare
8672968
to
853c8da
Compare
Hey @erwinmombay! These files were changed:
Hey @jridgewell! These files were changed:
|
src/internal-version.js
Outdated
@@ -24,5 +24,5 @@ | |||
* @return {string} | |||
*/ | |||
export function internalRuntimeVersion() { | |||
return '$internalRuntimeVersion$'; | |||
return INTERNAL_RUNTIME_VERSION; // eslint-disable-line no-undef |
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.
note: I could also add this to the eslint config, but wasn't sure if that were preferable
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 think the most unified solution, in keeping with the all-constants-in-one-file angle, would be to have a similar single forbidden-terms rule that uses one regex to test for /INTERNAL_RUNTIME_VERSION|IS_(FORTESTING|ESM|SXG|MINIFIED)/
and has a very short list of these files that use it (and maybe this particular file gets moved into #core/mode
after this PR). That way if we ever need to adjust build constants we can easily find a list of files that can use them.
This reverts commit 853c8da.
src/internal-version.js
Outdated
@@ -24,5 +24,5 @@ | |||
* @return {string} | |||
*/ | |||
export function internalRuntimeVersion() { | |||
return '$internalRuntimeVersion$'; | |||
return INTERNAL_RUNTIME_VERSION; // eslint-disable-line no-undef |
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 think the most unified solution, in keeping with the all-constants-in-one-file angle, would be to have a similar single forbidden-terms rule that uses one regex to test for /INTERNAL_RUNTIME_VERSION|IS_(FORTESTING|ESM|SXG|MINIFIED)/
and has a very short list of these files that use it (and maybe this particular file gets moved into #core/mode
after this PR). That way if we ever need to adjust build constants we can easily find a list of files that can use them.
const replacement = | ||
typeof value === 'boolean' | ||
? {type: 'booleanLiteral', value} | ||
: {type: 'stringLiteral', value}; |
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.
For your consideration; typechecking guarantees the possible results from typeof
const replacement = | |
typeof value === 'boolean' | |
? {type: 'booleanLiteral', value} | |
: {type: 'stringLiteral', value}; | |
const replacement = {value, type: `${typeof value}Literal`}; |
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.
Very clever! I don't know how I feel about this 🤔
Co-authored-by: Ryan Cebulko <ryan@cebulko.com>
Good ideas all around. I've made the relevant changes to this PR. |
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.
Thanks for simplifying our code! LGTM with one non-blocking suggestion.
@@ -24,5 +24,5 @@ | |||
* @return {string} | |||
*/ | |||
export function internalRuntimeVersion() { | |||
return '$internalRuntimeVersion$'; |
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.
For consistency, would it make sense to also remove the '$internalRuntimeVersion$'
sentinel from all the call-sites in unit tests, etc. and replace it with INTERNAL_RUNTIME_VERSION
?
https://github.com/ampproject/amphtml/search?q=%22%24internalRuntimeVersion%24%22
This might make it easier for a new engineer to search through the code while writing / debugging tests.
If you think it's worth it, doesn't have to be a part of this PR.
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.
Are you proposing we also do the var replacement at test time? If so, I agree. Seems like '$internalRuntimeVersion$'
is purely vestigial
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.
Exactly what I was thinking. IIRC, the only reason test code uses '$internalRuntimeVersion$'
is because src/internal-version.js
was using it. The sentinel can be anything we want it to be.
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.
Ok great. Will pursue this in a followup, since I can then do other related work in parallel
summary
This PR consolidates all of our build-time constants into a single file and babel transform. My hope is that this PR makes it easier to debug what our build constants are set to in each of our modes.
Transforms removed:
Notably this PR retains
amp-mode-transform
since it saves ~0.88kb from v0.mjs (as well as 0.1kb in most other binaries). What that transform does is replace any calls togetMode().minified
,getMode().localDev
andgetMode().development
to false in minified builds, often saving the need to import any code related to mode.additional info
Originally I tried to move this work to the bundlers. It is more standard to have bundlers insert build-time constants than for babel to do it. This is partially due to their built-in features like DCE. Closure also emits
uselessCode
warnings that we must suppress when constant replacement is done by a pre-closure babel transform.Unfortunately, closure doesn't support constant replacement in module mode (google/closure-compiler#1601), so I downscoped the idea to just consolidating our constants to a single location.
next steps
amp-mode-transformer
to minify all calls to the build constants.options
object passed throughout build-system instead of duplicating those calculations here.