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

Rollup #994

Merged
merged 7 commits into from
Apr 7, 2018
Merged

Rollup #994

merged 7 commits into from
Apr 7, 2018

Conversation

TrySound
Copy link
Contributor

@TrySound TrySound commented Jan 31, 2018

/cc @Andarist

.babelrc Outdated
@@ -83,7 +83,7 @@
"transform-runtime"
],
"presets": [
"env",
["env", { "modules": false }],
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd recommend to refactor this whole file. I usually just create .babelrc.js for better control (you have to put {"presets": ["./.babelrc.js"]} in you .babelrc so babel6 can handle it) and then I can just use javascript to construct plugins/presets based on process.env variables. It's imho hard to see what changes between various variants here, because of overwhelming duplication

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I'd also recommend using loose mode with modules: false in call cases + smth like

const cjs = process.env.NODE_ENV === 'test' || process.env.BABEL_ENV === 'cjs'
// ...
plugins: [
 // ...
 cjs && 'transform-es2015-modules-commonjs'
].filter(Boolean)

Why? loose mode for everything except commonjs transform, because it makes __esModule property enumerable, so I consider default mode better for this case.

rollup.config.js Outdated
}),
babel({
exclude: 'node_modules/**',
runtimeHelpers: true,
Copy link
Contributor

Choose a reason for hiding this comment

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

would be good to compare actual output for this and for the variant with plugins: ['external-helpers'] in case of umd build, I suspect that latter might be slightly better or there is no difference - im curious which one of those 2 😅

rollup.config.js Outdated
exclude: 'node_modules/**',
runtimeHelpers: true,
}),
uglify({
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 you are lacking a rollup-plugin-replace here which would replace process.env.NODE_ENV in your bundle

@Andarist
Copy link
Contributor

Good thinking with using rollup for just umd build first 👌

@bvaughn
Copy link
Owner

bvaughn commented Feb 2, 2018

😮 ... 🎉 😎

@codecov-io
Copy link

codecov-io commented Feb 7, 2018

Codecov Report

Merging #994 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #994   +/-   ##
=======================================
  Coverage   90.13%   90.13%           
=======================================
  Files          59       59           
  Lines        1653     1653           
=======================================
  Hits         1490     1490           
  Misses        163      163

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update af90cfe...1984e3c. Read the comment docs.

@TrySound
Copy link
Contributor Author

TrySound commented Feb 7, 2018

@Andarist could you take a look?

package.json Outdated
"build:es": "npm run clean:es && npm run build:types && cross-env NODE_ENV=production cross-env BABEL_ENV=es babel source --out-dir dist/es",
"build:umd": "npm run clean:umd && cross-env NODE_ENV=production webpack --config webpack.config.umd.js --bail",
"build:es": "npm run clean:es && npm run build:types && cross-env NODE_ENV=es babel source --out-dir dist/es",
"build:umd": "npm run clean:umd && cross-env NODE_ENV=rollup rollup -c",
Copy link
Contributor

Choose a reason for hiding this comment

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

i'd just use separate env var for this, let's keep NODE_ENV restricted to things like production, development, test etc

.babelrc.js Outdated
'source/TestUtils.js',
];

if (env === 'commonjs') {
Copy link
Contributor

Choose a reason for hiding this comment

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

personally I just construct a single module.exports based on env vars, so i just add plugins, presets (or modify some options) conditionally

that way I better see which plugins are common to all possible values and which ones differ

but whatever works for you :)

.babelrc.js Outdated
if (env === 'rollup') {
module.exports = {
comments: false,
plugins: ['external-helpers'],
Copy link
Contributor

Choose a reason for hiding this comment

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

technically this could be passed to rollup-plugin-babel and it would just merge it with what this .babelrc.js returns, that way you wouldn't have introduce separate env var just for rollup, but u'd somewhat loose 'centralization' of all babel configuration

i wouldnt concern much about the latter as its kinda temporary, because with babel@7 and its corresponding version of the babel plugin you won't have to deal with external-helpers at all, this optimization will be applies automatically by the plugin

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I'm gonna open PR with babel7 later

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

Successfully merging this pull request may close these issues.

4 participants