Skip to content
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

Closed
wants to merge 5 commits into from
Closed

♻️ Remove build.conf.js #27161

wants to merge 5 commits into from

Conversation

rcebulko
Copy link
Contributor

@rcebulko rcebulko commented Mar 9, 2020

Closes #27117

@amp-owners-bot
Copy link

amp-owners-bot bot commented Mar 9, 2020

Hey @erwinmombay, these files were changed:

build-system/compile/single-pass.js

OWNERS Show resolved Hide resolved
babel.config.js Show resolved Hide resolved
babel.config.js Show resolved Hide resolved
},
],
['@babel/plugin-transform-react-jsx', jsxOpts],
localPlugin('transform-inline-configure-component'),
Copy link
Contributor

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.

Copy link
Contributor

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):

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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:

  1. Change ERROR to DEBUG to see what Karma is doing

    logLevel: 'ERROR',

  2. Change process.stdout.write('.') here to console.log(<file being transformed>)

    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()
Copy link
Contributor

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.

Copy link
Contributor Author

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) {
Copy link
Contributor

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.

Copy link
Contributor

@rsimha rsimha left a 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 = {
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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'),
Copy link
Contributor

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):

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.

babel.config.js Show resolved Hide resolved
babel.config.js Show resolved Hide resolved
@@ -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');
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@rsimha rsimha left a 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 = {
Copy link
Contributor

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'),
Copy link
Contributor

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:

  1. Change ERROR to DEBUG to see what Karma is doing

    logLevel: 'ERROR',

  2. Change process.stdout.write('.') here to console.log(<file being transformed>)

    bundle.on('transform', function(tr) {
    if (tr instanceof babelify) {
    tr.once('babelify', function() {
    process.stdout.write('.');
    });
    }
    });

@jridgewell does this SGTY?

Copy link
Contributor

@jridgewell jridgewell left a 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');
}

@rcebulko
Copy link
Contributor Author

@jridgewell Gotcha, thanks for clarifying. I have a much better picture now of what the goal state looks like.

@rsimha
Copy link
Contributor

rsimha commented Mar 30, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove build.conf.js
4 participants