Skip to content

[wip] Babel support #39

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

[wip] Babel support #39

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,7 @@
"acorn-jsx": "4.1.0",
"asyncro": "^2.0.1",
"autoprefixer": "^7.2.3",
"babel-plugin-external-helpers": "^6.22.0",
"babel-polyfill": "^6.26.0",
"camelcase": "^4.1.0",
"chalk": "^2.3.0",
Expand All @@ -44,6 +45,7 @@
"pretty-bytes": "^4.0.2",
"regenerator-runtime": "^0.11.1",
"rollup": "^0.52.1",
"rollup-plugin-babel": "^3.0.3",
"rollup-plugin-buble": "^0.18.0",
"rollup-plugin-bundle-size": "^1.0.1",
"rollup-plugin-commonjs": "^8.2.6",
Expand Down
15 changes: 11 additions & 4 deletions src/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@ import { rollup, watch } from 'rollup';
import nodent from 'rollup-plugin-nodent';
import commonjs from 'rollup-plugin-commonjs';
import nodeResolve from 'rollup-plugin-node-resolve';
import babel from 'rollup-plugin-babel';
import buble from 'rollup-plugin-buble';
import uglify from 'rollup-plugin-uglify';
import postcss from 'rollup-plugin-postcss';
Expand Down Expand Up @@ -76,7 +77,7 @@ export default async function microbundle(options) {
let steps = [];
for (let i=0; i<entries.length; i++) {
for (let j=0; j<formats.length; j++) {
steps.push(createConfig(options, entries[i], formats[j]));
steps.push(await createConfig(options, entries[i], formats[j]));
}
}

Expand Down Expand Up @@ -121,8 +122,8 @@ export default async function microbundle(options) {
}


function createConfig(options, entry, format) {
let { pkg } = options;
async function createConfig(options, entry, format) {
let { pkg, cwd } = options;

let external = ['dns', 'fs', 'path', 'url'].concat(
Object.keys(pkg.peerDependencies || {}),
Expand Down Expand Up @@ -168,6 +169,8 @@ function createConfig(options, entry, format) {
let cjsMain = replaceName(pkg['cjs:main'] || 'x.js', mainNoExtension);
let umdMain = replaceName(pkg['umd:main'] || 'x.umd.js', mainNoExtension);

const useBabel = !!pkg.babel || await isFile(resolve(cwd, './.babelrc')) || await isFile(resolve(cwd, './.babelrc.js'));
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking that, as long as we can get a default babel config that is as optimized as Bublé, we can just default to Babel.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good stuff happening in terms of babel@7 in terms of outputting better tree-shakeable code & more concise/performant code, but it's still a beta. Im pretty confident in it, we have a comprehensive test suite after all, so I'm using it all over the place - aint sure though if we should promote it just yet as part of other tool (microbundle in this context) as it has potential to break some stuff. And also it might not be yet compatible with some other tooling as not every tool had an opportunity to catch up yet and provide support for it.

If we are gonna default to babel@7, Im wondering how do you plan to support babel configs? Or maybe you'd like to ignore it all along and just use internal, optimized one? Im not sure how the whole thing applies to your 0 configuration goal 😉

Personally I'd say it's better to read the real babel config, but then I'm not sure how we should "optimize" it. Mutating the input and i.e. parsing it to add loose option to plugins & presets seems a little bit magical. If one specify his/her config we should just use it as is, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idea - we could possibly support babel config files without any magic, read the config files (only for validation) with some utility exposed by babel like this one and parse it (ideally we could just receive the result from babel in JSON) to warn people against using non-loose / costly stuff. WDYT?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Andarist I spoke to Henry and I believe he mentioned they pulled the configuration parsing & lookup out of Babel into a standalone module. Maybe we can use that now?

+1 for warning, though it'd be nice to have a way to use a "stock" babel config and let microbundle tweak it into loose mode.


// let rollupName = safeVariableName(basename(entry).replace(/\.js$/, ''));

let config = {
Expand Down Expand Up @@ -195,7 +198,11 @@ function createConfig(options, entry, format) {
}
}
}),
buble({
useBabel && babel({
exclude: 'node_modules/**',
plugins: ['external-helpers']
}),
!useBabel && buble({
exclude: 'node_modules/**',
jsx: options.jsx || 'h',
objectAssign: options.assign || 'Object.assign',
Expand Down