-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Conversation
needs https://npm.im/process |
b7e7517
to
72583f0
Compare
rebased onto |
72583f0
to
ca71ddc
Compare
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 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 |
The failing Netlify deploy is something about spriting opencollective images, which also happens on other branches. I'll look into that somewhere else |
This means our code plus the code of our dependencies will be transpiled, right? |
I'm pretty sure the current config will also transpile |
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.
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?
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.
@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).
@Munter I tried to make this test. But I can't get your branch Edit: I cleaned the Edit2: By adding |
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 |
My local output shows:
These two empty chunks look odd. In Travis' logfile you don't find such a warning. |
What about this rollup-plugin-glob-import? |
@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 |
@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 |
I'll give this a try on windows too |
I'm running this side-by-side on mac and windows, and the result of |
alright, the difference is just some object prop ordering. but I can definitely reproduce the "can't run browser tests on windows" problem :( |
it creates an empty bundle. we see warnings
the contents of the bundle: (function () {
'use strict';
}());
//# sourceMappingURL=f16fa37b-ce80-4765-8342-10dd7125ff93.rollup.js.map |
I'm unsure what the root cause is here. perhaps there's something in karma that demands POSIX paths? |
Signed-off-by: Christopher Hiller <[email protected]>
(someone needs to rebase this manually before merging) |
bf3662e
to
5b08dec
Compare
I marked this @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. 😄 |
@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. |
I'd like to see if I can silence a few of the rollup warnings before we merge |
…on and aliasing" This reverts commit 207ef63.
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
Set up eslint to keep the code node compatible at a version we decidemocha.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.