-
Notifications
You must be signed in to change notification settings - Fork 20.6k
Build: Make Karma work in ES modules mode #4550
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
Conversation
ef9152f
to
5a8e212
Compare
The issue to solve before landing this is that one test fails in
I don't understand why as |
057f819
to
c29f6bf
Compare
What's also interesting is that the above test fails in Chrome but not in Firefox (headless or not). |
OK, I know why it only failed in Chrome - this is because the Interesting that it only happens in esmodules mode, though. |
93ba5c0
to
1d83394
Compare
test/karma.context.html
Outdated
}); | ||
// Workaround: Remove call to `window.__karma__.loaded()` | ||
// in favour of calling `window.__karma__.start()` from `loadTests()` | ||
// because tests such as unit/ready.js should run after document ready. |
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.
Why have extra indentation 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.
Ouch, it should be using spaces, not tabs, as the rest of the file.
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.
Fixed.
Also, run such a suite in CI to make sure modules are working as expected when used directly.
@timmywil @gibson042 I realized I broke local PHP esmodules mode in #4554 (AMD mode works but that's less useful on |
@gibson042 I pushed two new commits; the last one only reformats the Karma HTML files to use tabs as other files do; otherwise my IDE was listening to |
I pushed another commit that makes Karma AMD tests invoked on Travis. Based on this PR, it should be easy to enable Karma AMD testing on 3.x, finally getting rid of accidental failures that were introduced there from time to time. |
Also, run such a suite in CI to make sure modules are working as expected when used directly. (partially cherry picked from 341c6d1) Ref jquerygh-4550
Also, run such a suite in CI to make sure modules are working as expected when used directly. (partially cherry picked from 341c6d1) Ref jquerygh-4550
PR jquerygh-4550 added support for running ES modules & AMD tests via Karma. This required reading the `esmodules` & `amd` props from both `QUnit.config` & `QUnit.urlParams`. By picking these two properties manually, the `dev` one stopped being respected while ones handled directly by QUnit were fine (like `hidepassed`). Instead of maintaining the full list of options, the code now iterates over QUnit URL config and handles the fallbacks in a more generic way. Apart from that, all jQuery source & test files are now read directly from disk instead of being cached by Karma so that one can run `grunt karma:chrome-debug` & work on a fix without restarting that Karma run after each change. A similar effect could have been achieved by setting `autoWatch` to `true` but then the main Karma page runs tests in an iframe by default when `grunt karma:chrome-debug` is run instead of relying on the current debug flow. Ref jquerygh-4550
PR jquerygh-4550 added support for running ES modules & AMD tests via Karma. This required reading the `esmodules` & `amd` props from both `QUnit.config` & `QUnit.urlParams`. By picking these two properties manually, the `dev` one stopped being respected while ones handled directly by QUnit were fine (like `hidepassed`). Instead of maintaining the full list of options, the code now iterates over QUnit URL config and handles the fallbacks in a more generic way. Apart from that, all jQuery source & test files are now read directly from disk instead of being cached by Karma so that one can run `grunt karma:chrome-debug` & work on a fix without restarting that Karma run after each change. A similar effect could have been achieved by setting `autoWatch` to `true` but then the main Karma page runs tests in an iframe by default when `grunt karma:chrome-debug` is run instead of relying on the current debug flow. Ref jquerygh-4550
PR jquerygh-4550 added support for running ES modules & AMD tests via Karma. This required reading the `esmodules` & `amd` props from both `QUnit.config` & `QUnit.urlParams`. By picking these two properties manually, the `dev` one stopped being respected while ones handled directly by QUnit were fine (like `hidepassed`). Instead of maintaining the full list of options, the code now iterates over QUnit URL config and handles the fallbacks in a more generic way. Apart from that, all jQuery source & test files are now read directly from disk instead of being cached by Karma so that one can run `grunt karma:chrome-debug` & work on a fix without restarting that Karma run after each change. A similar effect could have been achieved by setting `autoWatch` to `true` but then the main Karma page runs tests in an iframe by default when `grunt karma:chrome-debug` is run instead of relying on the current debug flow. Ref jquerygh-4550
PR jquerygh-4550 added support for running ES modules & AMD tests via Karma. This required reading the `esmodules` & `amd` props from both `QUnit.config` & `QUnit.urlParams`. By picking these two properties manually, the `dev` one stopped being respected while ones handled directly by QUnit were fine (like `hidepassed`). Instead of maintaining the full list of options, the code now iterates over QUnit URL config and handles the fallbacks in a more generic way. Apart from that, all jQuery source & test files are now read directly from disk instead of being cached by Karma so that one can run `grunt karma:chrome-debug` & work on a fix without restarting that Karma run after each change. A similar effect could have been achieved by setting `autoWatch` to `true` but then the main Karma page runs tests in an iframe by default when `grunt karma:chrome-debug` is run instead of relying on the current debug flow. Ref jquerygh-4550
PR jquerygh-4550 added support for running ES modules & AMD tests via Karma. This required reading the `esmodules` & `amd` props from both `QUnit.config` & `QUnit.urlParams`. By picking these two properties manually, the `dev` one stopped being respected while ones handled directly by QUnit were fine (like `hidepassed`). Instead of maintaining the full list of options, the code now iterates over QUnit URL config and handles the fallbacks in a more generic way. Apart from that, all jQuery source & test files are now read directly from disk instead of being cached by Karma so that one can run `grunt karma:chrome-debug` & work on a fix without restarting that Karma run after each change. A similar effect could have been achieved by setting `autoWatch` to `true` but then the main Karma page runs tests in an iframe by default when `grunt karma:chrome-debug` is run instead of relying on the current debug flow. Ref jquerygh-4550
PR jquerygh-4550 added support for running ES modules & AMD tests via Karma. This required reading the `esmodules` & `amd` props from both `QUnit.config` & `QUnit.urlParams`. By picking these two properties manually, the `dev` one stopped being respected while ones handled directly by QUnit were fine (like `hidepassed`). Instead of maintaining the full list of options, the code now iterates over QUnit URL config and handles the fallbacks in a more generic way. Apart from that, all jQuery source & test files are now read directly from disk instead of being cached by Karma so that one can run `grunt karma:chrome-debug` & work on a fix without restarting that Karma run after each change. A similar effect could have been achieved by setting `autoWatch` to `true` but then the main Karma page runs tests in an iframe by default when `grunt karma:chrome-debug` is run instead of relying on the current debug flow. Ref jquerygh-4550
PR gh-4550 added support for running ES modules & AMD tests via Karma. This required reading the `esmodules` & `amd` props from both `QUnit.config` & `QUnit.urlParams`. By picking these two properties manually, the `dev` one stopped being respected while ones handled directly by QUnit were fine (like `hidepassed`). Instead of maintaining the full list of options, the code now iterates over QUnit URL config and handles the fallbacks in a more generic way. Apart from that, all jQuery source & test files are now read directly from disk instead of being cached by Karma so that one can run `grunt karma:chrome-debug` & work on a fix without restarting that Karma run after each change. A similar effect could have been achieved by setting `autoWatch` to `true` but then the main Karma page runs tests in an iframe by default when `grunt karma:chrome-debug` is run instead of relying on the current debug flow. Closes gh-4574 Ref gh-4550
Also, run such a suite in CI to make sure modules are working as expected when used directly. (partially cherry picked from 341c6d1) Ref jquerygh-4550 Ref jquerygh-4574
Also, run such a suite in CI to make sure modules are working as expected when used directly. (partially cherry picked from 341c6d1) (partially cherry picked from 437f389) Ref jquerygh-4550 Ref jquerygh-4574
Also, run such a suite in CI to make sure modules are working as expected when used directly. (partially cherry picked from 341c6d1) (partially cherry picked from 437f389) Ref jquerygh-4550 Ref jquerygh-4574
PR jquerygh-4550 added support for running ES modules & AMD tests via Karma. This required reading the `esmodules` & `amd` props from both `QUnit.config` & `QUnit.urlParams`. By picking these two properties manually, the `dev` one stopped being respected while ones handled directly by QUnit were fine (like `hidepassed`). Instead of maintaining the full list of options, the code now iterates over QUnit URL config and handles the fallbacks in a more generic way. Apart from that, all jQuery source & test files are now read directly from disk instead of being cached by Karma so that one can run `grunt karma:chrome-debug` & work on a fix without restarting that Karma run after each change. A similar effect could have been achieved by setting `autoWatch` to `true` but then the main Karma page runs tests in an iframe by default when `grunt karma:chrome-debug` is run instead of relying on the current debug flow. Closes jquerygh-4574 Ref jquerygh-4550
Summary
Make Karma work in ES modules mode
Also, run such a suite in CI to make sure modules are working as expected
when used directly.
We could consider doing a version of this PR for AMD for 3.x-stable, I don't see any fundamental roadblocks.
Checklist
If needed, a docs issue/PR was created at https://github.com/jquery/api.jquery.com