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 and babel in build pipeline #4293

Merged
merged 24 commits into from Jul 2, 2020
Merged

Rollup and babel in build pipeline #4293

merged 24 commits into from Jul 2, 2020

Conversation

Munter
Copy link
Member

@Munter Munter commented May 17, 2020

We want to modernize the code base, and in order to do so we need to add a transpilation step for building the browser artifacts we distribute, so we can retain our current conservative browser version targets.

The strategy I suggest is applying Babel in our bundling tool to keep the output browser compatible. I suggest switching from browserify to Babel to give us an ability to move to ES modules when we want to, but alsy get the immediate option of creating multiple distributions with different configurations of transpilation applied.

When these changes are all done we should be able to convert the code base to more modern js, allowing things like destructuring, arrow functions etc.

Description of the Change

  • Clean up code paths, so node-only code isn't part of a browser bundles dependency graph
  • Replace Browserify with Rollup
  • Set up eslint to keep the code node compatible at a version we decide
  • Add Babel transpilation to rollup bundles
    • Configure browser output that is IE11 compatible --> mocha.js
    • Configure a more modern output for evergreen browsers --> mocha.modern.js?

Alternate Designs

We could have retained browserify as our bundling tool, but rollup was chosen for its ability to deal with ES modules, which is a very likely future for Mocha, given its browser nature.

Benefits

No more restrictions on authors to write ES5 and remember what browser globals were available 7 years ago

Possible Drawbacks

Changing bundling strategy can carry a risk, especially if the bundler changes the way it resolves node global for a browser.

Applying transpilation can carry a risk of not knowing the exact output that will be generated.

We need to test these changes very well.

@Munter Munter marked this pull request as draft May 17, 2020 10:39
@coveralls
Copy link

coveralls commented May 17, 2020

Coverage Status

Coverage increased (+0.2%) to 93.932% when pulling 7739689 on munter/transpilation into e30ae28 on master.

@boneskull
Copy link
Member

needs https://npm.im/process

@boneskull
Copy link
Member

rebased onto master

@Munter Munter marked this pull request as ready for review June 13, 2020 07:02
@Munter
Copy link
Member Author

Munter commented Jun 13, 2020

This branch is ready to be merged IMO. All the transpilation config has been added, which makes the code base ready to be converted to modern JS.

I made an example branch where I ran lebab -t arrow on our lib files: https://github.com/mochajs/mocha/compare/munter/transpilation...munter/lebab?expand=1
The travis build for that is green, meaning that it runs in IE11, where arrow functions would normally throw: https://travis-ci.org/github/mochajs/mocha

I think we should merge this branch separately from doing the actual code modernisation, as an attempt to keep the change-set as small as possible here and make it easier to coordinate when we pull in modernisations that will likely require other branches to resolve conflicts

@Munter
Copy link
Member Author

Munter commented Jun 13, 2020

The failing Netlify deploy is something about spriting opencollective images, which also happens on other branches. I'll look into that somewhere else

@Munter Munter requested review from boneskull and a team June 13, 2020 07:08
@juergba
Copy link
Member

juergba commented Jun 15, 2020

The strategy I suggest is applying Babel in our bundling tool to keep the output browser compatible.

This means our code plus the code of our dependencies will be transpiled, right?

@Munter
Copy link
Member Author

Munter commented Jun 15, 2020

This means our code plus the code of our dependencies will be transpiled, right?

I'm pretty sure the current config will also transpile node_modules, but I haven't actually tested it. Maybe we should make a new branch based on this one and upgrade a dependency we know will break IE11. The Travis build should tell us if it works

Copy link
Member

@boneskull boneskull left a comment

Choose a reason for hiding this comment

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

great work. pls see my comments etc. mostly questions, but a couple things I'd like changed (none of them are huge)

how do we get away with removing lib/browser/tty.js?

are there any breaking changes here?

.gitignore Show resolved Hide resolved
lib/reporters/base.js Outdated Show resolved Hide resolved
lib/reporters/base.js Show resolved Hide resolved
package-scripts.js Show resolved Hide resolved
scripts/karma-rollup-plugin.js Show resolved Hide resolved
lib/cli/lookupFiles.js Outdated Show resolved Hide resolved
package.json Show resolved Hide resolved
rollup.config.js Outdated Show resolved Hide resolved
rollup.config.js Outdated Show resolved Hide resolved
test/unit/parseQuery.spec.js Outdated Show resolved Hide resolved
Copy link
Member

@juergba juergba left a comment

Choose a reason for hiding this comment

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

@Munter from a bird's-eye view this PR makes sense and looks good to me. I can't evaluate the details though. We should take the risk and merge it (after addressing @boneskull's comments).

.browserslistrc Show resolved Hide resolved
scripts/karma-rollup-plugin.js Outdated Show resolved Hide resolved
scripts/karma-rollup-plugin.js Outdated Show resolved Hide resolved
@juergba
Copy link
Member

juergba commented Jun 19, 2020

Maybe we should make a new branch based on this one and upgrade a dependency we know will break IE11.

@Munter I tried to make this test. But I can't get your branch munter/transpilation (unchanged) running on my local Windows machine. npm test fails at script test.browser.unit with code ELIFECYCLE. The bundling of ./mocha.js succeeds with a warning of circular dependencies, but above script fails.

Edit: I cleaned the npm cache, deleted the node_modules folder and package-lock.json file. Then npm install. The browser tests fail. I don't know wether this is a local problem on my laptop only, since we don't run any browser tests on Appveyor.

Edit2: By adding failOnEmptyTestSuite: false to karma.conf.js, npm test passes, but no browser tests are run. The summary always states: SUMMARY: √ 0 tests completed.
So the root problem is, the karma-runner does not execute any tests on Windows.

package.json Show resolved Hide resolved
karma.conf.js Show resolved Hide resolved
@Munter
Copy link
Member Author

Munter commented Jun 20, 2020

adding failOnEmptyTestSuite: false to karma.conf.js, npm test passes, but no browser tests are run. The summary always states: SUMMARY: √ 0 tests completed.
So the root problem is, the karma-runner does not execute any tests on Windows.

I'd say this is a blocker. You should be able to develop locally on windows.

I'm a bit confused why our tests from saucelabs are not representative of your experience here.

const browserPlatformPairs = {
  'chrome@latest': 'Windows 10',
  'MicrosoftEdge@latest': 'Windows 10',
  'internet explorer@latest': 'Windows 10',
  'firefox@latest': 'Windows 10',
  'safari@latest': 'macOS 10.13'
};

I guess it could be something with the bundling mechanism, since the saucelabs tests are run on linux bundled assets I think.

Maybe we need appveyor to run an additional test of karma and a local headless chrome

@juergba
Copy link
Member

juergba commented Jun 20, 2020

My local output shows:

nps is executing `test.browser.unit` : cross-env NODE_PATH=. karma start --single-run
CI mode disabled

START:
babelHelpers: 'bundled' option was used by default. It is recommended to configure this option explicitly, read more here: 
https://github.com/rollup/plugins/tree/master/packages/babel#babelhelpers
Generated an empty chunk: "_rollup:plugin-multi-entry:entry-point"
Generated an empty chunk: "_rollup:plugin-multi-entry:entry-point"
20 06 2020 16:00:19.035:INFO [karma-server]: Karma v4.4.1 server started at http://0.0.0.0:9876/
20 06 2020 16:00:19.046:INFO [launcher]: Launching browsers ChromeHeadless with concurrency unlimited
20 06 2020 16:00:19.070:INFO [launcher]: Starting browser ChromeHeadless
20 06 2020 16:00:22.356:INFO [HeadlessChrome 83.0.4103 (Windows 10.0.0)]: Connected on socket NylQbcaiMkoAHu2QAAAA with id 
56280182

Finished in 0.012 secs / 0 secs @ 16:00:22 GMT+0200 (GMT+02:00)

SUMMARY:
√ 0 tests completed

These two empty chunks look odd. In Travis' logfile you don't find such a warning.

@juergba
Copy link
Member

juergba commented Jun 20, 2020

What about this rollup-plugin-glob-import?
Doesn't it bundle multi test files (also glob's) into one single test file?

@Munter
Copy link
Member Author

Munter commented Jun 21, 2020

What about this rollup-plugin-glob-import?
Doesn't it bundle multi test files (also glob's) into one single test file?

@juergba That plugin works on globs in import statements in code. Useful if you want to bundle thing you can't statically analyse the need for. Like icons or dynamic content etc. We could possibly use it, but only if we created a new entry file for each of our test branches from Karma and import those globs. I'm unsure how that would work with a new wrapper layer i import/exports. It didn't seem very appealing

@Munter
Copy link
Member Author

Munter commented Jun 21, 2020

These two empty chunks look odd. In Travis' logfile you don't find such a warning

@juergba I think I might have messed something up that caused the different windows paths with backslashes not to match in the plugin. I'll be at the office tomorrow and will bring home a windows laptop so I have a setup I can recreate and fix it in.

I still think it would be a good idea to add an appveyor test for running headless chrome tests on windows

@boneskull
Copy link
Member

I'll give this a try on windows too

@boneskull
Copy link
Member

I'm running this side-by-side on mac and windows, and the result of nps build is different. windows builds one thing, and mac builds something else.

@boneskull
Copy link
Member

alright, the difference is just some object prop ordering.

but I can definitely reproduce the "can't run browser tests on windows" problem :(

@boneskull
Copy link
Member

it creates an empty bundle. we see warnings

Generated an empty chunk: "_rollup:plugin-multi-entry:entry-point"
Generated an empty chunk: "_rollup:plugin-multi-entry:entry-point"

the contents of the bundle:

(function () {
	'use strict';



}());
//# sourceMappingURL=f16fa37b-ce80-4765-8342-10dd7125ff93.rollup.js.map

@boneskull
Copy link
Member

OK, 008da88 should fix it. @juergba can you give it a shot?

@boneskull
Copy link
Member

I'm unsure what the root cause is here. perhaps there's something in karma that demands POSIX paths?

@boneskull
Copy link
Member

(someone needs to rebase this manually before merging)

@boneskull boneskull added type: chore generally involving deps, tooling, configuration, etc. area: repository tooling concerning ease of contribution semver-patch implementation requires increase of "patch" version number; "bug fixes" labels Jul 1, 2020
@boneskull
Copy link
Member

I marked this patch but I'm not entirely confident it won't break somebody.

@mantoni I wanted to let you know that this exists and will be merged soon. I am not sure if this is going to be good or bad for you, or neither. 😄

@mantoni
Copy link
Contributor

mantoni commented Jul 2, 2020

@boneskull Thank you for thinking of me. My current experiments with a rewrite of Mochify depend on the pre-bundled version of Mocha. So this won't be an issue.

@Munter
Copy link
Member Author

Munter commented Jul 2, 2020

I'd like to see if I can silence a few of the rollup warnings before we merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: repository tooling concerning ease of contribution semver-patch implementation requires increase of "patch" version number; "bug fixes" type: chore generally involving deps, tooling, configuration, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants