-
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
♻️ Remove build.conf.js #27161
♻️ Remove build.conf.js #27161
Conversation
Hey @erwinmombay, these files were changed:
|
}, | ||
], | ||
['@babel/plugin-transform-react-jsx', jsxOpts], | ||
localPlugin('transform-inline-configure-component'), |
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.
build.conf
is only used in dist
and check-types
. This plugin and below should not be used for test
.
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.
Good catch. Some context on testing below:
This is how Karma is set up to run babelify
transforms on test code (using browserify
):
amphtml/build-system/tasks/karma.conf.js
Lines 75 to 83 in 3488672
browserify: { | |
watch: true, | |
debug: true, | |
fast: true, | |
basedir: __dirname + '/../../', | |
transform: [['babelify', BABELIFY_CONFIG]], | |
// Prevent "cannot find module" errors on Travis. See #14166. | |
bundleDelay: isTravisBuild() ? 5000 : 1200, | |
}, |
It should be possible to enable debugging for browserify
and run gulp unit --files <some file>
to see the exact config being picked up by babelify
.
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.
Would you mind clarifying what about this is borked, given that it is unchanged from when it lived in build.conf.js
? This defaultPlugins
method is not used for testing AFAICT. karma.conf.js
gets BABELIFY_PLUGINS
from helpers.js
, which looks like this:
const BABELIFY_PLUGINS = {
plugins: [
conf.getReplacePlugin(argv.esm || false),
conf.getJsonConfigurationPlugin(),
],
};
Unless I'm missing something, this PR should be a no-op. As I mention elsewhere I'm happy to clean up/refactor this and anything else (in separate PRs), but I can't tell how this change would have downstream impacts.
Also @rsimha I'm not sure what you were trying to link to there. AFAICT there's no flag that does anything like increase verbosity or display what config is picked up by babelify
; here, debug
is already set and all that does is add a source map. I could just log the BABELIFY_CONFIG
, but It can tell how that's constructed anyway. Was there something specific you had in mind or was your intent to more generally point me at documentation?
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.
If Karma directly uses BABELIFY_PLUGINS
and all tests pass with this PR, I think that's good enough.
I was trying to link to a way to print the list of files being transformed. I guess that link was the wrong one. There are two more Karma tricks that might help:
-
Change
ERROR
toDEBUG
to see what Karma is doing
amphtml/build-system/tasks/karma.conf.js
Line 139 in 286109a
logLevel: 'ERROR', -
Change
process.stdout.write('.')
here toconsole.log(<file being transformed>)
amphtml/build-system/tasks/runtime-test/runtime-test-base.js
Lines 198 to 204 in 286109a
bundle.on('transform', function(tr) { if (tr instanceof babelify) { tr.once('babelify', function() { process.stdout.write('.'); }); } });
@jridgewell does this SGTY?
argv._.includes('dist') || argv._.includes('check-types'); | ||
const {esm} = argv; | ||
const noModuleTarget = { | ||
'browsers': isTravisBuild() |
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 only want this if in single-pass.
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 saying that's how it works now and something has changed, or that's not how it works now but it should be fixed? [original code]
// Closure Compiler builds do not use any of the default settings below until its | ||
// an esm build. (Both Multipass and Singlepass) | ||
// Closure Compiler builds do not use any of the default settings below until | ||
// its an esm build. (Both Multipass and Singlepass) | ||
if (isClosureCompiler && !esm) { |
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 want to use dist plugins here.
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 taking on this work. Some preliminary comments below.
? ['Last 2 versions', 'safari >= 9'] | ||
: ['Last 2 versions'], | ||
|
||
const jsxOpts = { |
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 this refactor is a good opportunity to document each of these constants with a short comment. @jridgewell, @erwinmombay, or I can help with the ones that aren't obvious.
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 felt it made sense to just embed these options directly in the plugin list below, which makes it fairly clear that they are options to the React transformer. SGTY?
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 idea of separating things like jsxOpts
into constants was to make the main plugin code more readable. Documenting this in a separate PR SGTM.
}, | ||
], | ||
['@babel/plugin-transform-react-jsx', jsxOpts], | ||
localPlugin('transform-inline-configure-component'), |
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.
Good catch. Some context on testing below:
This is how Karma is set up to run babelify
transforms on test code (using browserify
):
amphtml/build-system/tasks/karma.conf.js
Lines 75 to 83 in 3488672
browserify: { | |
watch: true, | |
debug: true, | |
fast: true, | |
basedir: __dirname + '/../../', | |
transform: [['babelify', BABELIFY_CONFIG]], | |
// Prevent "cannot find module" errors on Travis. See #14166. | |
bundleDelay: isTravisBuild() ? 5000 : 1200, | |
}, |
It should be possible to enable debugging for browserify
and run gulp unit --files <some file>
to see the exact config being picked up by babelify
.
@@ -19,7 +19,7 @@ const babelify = require('babelify'); | |||
const browserify = require('browserify'); | |||
const buffer = require('vinyl-buffer'); | |||
const colors = require('ansi-colors'); | |||
const conf = require('../compile/build.conf'); | |||
const conf = require('../../babel.config'); |
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.
@jridgewell Based on this documentation, I think we should eventually eliminate the require
-ing of babel.config.js
and refactor code in files like this. WDYT?
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 with this; it was odd to see. That being said, I think that's why build.conf.js
may have existed separately in the first place: to define those shared methods somewhere for other files to use. It wasn't clear how much boy-scouting was desired here, or if the goal was to just combine them, so I went conservative the first time around. I'd be happy to refactor/clean this up a bit; will defer to your judgement on how much of that should happen here vs. in a follow-up refactor 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.
No more blocking comments from me. Will let @jridgewell review and approve the rest.
? ['Last 2 versions', 'safari >= 9'] | ||
: ['Last 2 versions'], | ||
|
||
const jsxOpts = { |
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 idea of separating things like jsxOpts
into constants was to make the main plugin code more readable. Documenting this in a separate PR SGTM.
}, | ||
], | ||
['@babel/plugin-transform-react-jsx', jsxOpts], | ||
localPlugin('transform-inline-configure-component'), |
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.
If Karma directly uses BABELIFY_PLUGINS
and all tests pass with this PR, I think that's good enough.
I was trying to link to a way to print the list of files being transformed. I guess that link was the wrong one. There are two more Karma tricks that might help:
-
Change
ERROR
toDEBUG
to see what Karma is doing
amphtml/build-system/tasks/karma.conf.js
Line 139 in 286109a
logLevel: 'ERROR', -
Change
process.stdout.write('.')
here toconsole.log(<file being transformed>)
amphtml/build-system/tasks/runtime-test/runtime-test-base.js
Lines 198 to 204 in 286109a
bundle.on('transform', function(tr) { if (tr instanceof babelify) { tr.once('babelify', function() { process.stdout.write('.'); }); } });
@jridgewell does this SGTY?
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 issue is a misunderstanding with my issue request. Right now, we're configuring babel in multiple places, which leads to a lot of confusion on how to enable plugins for everything. I want to remove every single { plugins: [...] }
passed to babel.
To do that, we need to move all configuration into babel.config.js
. Don't export any extra methods, anything, from this module. babel.transform()
will load the file itself, the config file returns the appropriate configuration, and that's it.
We currently have 4 modes (I think): test
, build
, dist
, dist-single-pass
. What should be done is to separate these modes into individual, internal, functions. We can then reduce the default export function to a simple:
module.exports = function(api) {
api.cache(true);
if (singlePass) return configureSinglePass();
if (dist) return configureDist();
if (build) return configureBuild();
if (test) return configureTest();
throw new Error('unknown build configuration');
}
@jridgewell Gotcha, thanks for clarifying. I have a much better picture now of what the goal state looks like. |
I've messed with this code a fair bit recently, so I'll pick up from where Ryan left off. Edit: I had to abandon the approach of using this PR as a starting point. Updated refactor has been merged, so this PR can be closed. |
Closes #27117