Comments (6)
@NullVoxPopuli Yes, we have a Matrix room at https://app.gitter.im/#/room/#qunitjs_qunit:gitter.im (webchat), or via other clients: https://matrix.to/#/#qunitjs_qunit:gitter.im
from qunit.
I don't think of QUnit as a library one is meant to bundle. Most test runners afaik share that sentiment, in that test runner generally act on your behalf to run your tests, and your tests import your application code (possibly built/compiled), and the test framework is either imported by your test files (which would not be compiled or built) or ahead of time by the test runner itself.
In the case of AMD, there's usually a top-level file for the app and for the test, where test.html
file would first load QUnit and their AMD loader, and then load their tests/application code from there.
I worry that requiring them to have a separate build just for QUnit would lower dev experience, and potentially decrease confidence in the test result as it means they would no longer integrate with their main build (or have a separate build that contains only QUnit, hence why we added upstream support at some point).
The projects I'm aware of that use QUnit and AMD, would, I suspect not benefit from this change. Do you agree?
I am open to dropping native support, but perhaps not for the same reasons as you.
For example, if it becomes a burden to support we could instead recommend that projects build their own qunit.amd.js
file. It seems likely that such project might actually not be building any other AMD files yet. For example https://github.com/kiwix/kiwix-js/tree/3.9.0/, used AMD to directly load all test and production source files. (No bundling, it's an offline web app.) They'd have to build a variant of QUnit just to load their tests? Or do you propose we merely remove this from the src but still create an AMD variant during our own release process?
It looks like for ESM we'll need a separate distribution indeed since it's hard to import CJS directly in ESM, and transform services seem to currenlty misunderstand our exports (per #1724), so providing our own one would make that work directly, possibly even without needig to enumerate each export by name (we have quite a few).
For AMD, it seems like it'd be trivial to continue support in the non-ESM ("CJS") distribution with these three lines of code as-is.
from qunit.
I worry that requiring them to have a separate build just for QUnit would lower dev experience
Given that this works: https://jsbin.com/fipayiy/edit?html,output,
I don't think we need to support any target format other than ESM.
if it becomes a burden to support we could instead recommend that projects build their own
If folks are still using AMD without a tool to build AMD for them, then I think a wrapper script / build would be fine.
The main thing I want to get away from is the single file supporting every format in existence.
Or do you propose we merely remove this from the src but still create an AMD variant during our own release process?
yeah, I am ok with this.
I'm a big fan of:
- author only in one format
- build to all supported formats
- test all supported formats in an isolated way via monorepo (which gives us the most realistic way to reference our built project)
it's hard to import CJS directly in ESM,
and transform services
this happens in tool-less situations (local browser) as well. transform services are irrelevant.
For AMD, it seems like it'd be trivial to continue support in the non-ESM ("CJS") distribution with these three lines of code as-is.
yeah, and if we need to bundle an IIFE format, AMD is IIFE + the 3 lines easy peasy.
from qunit.
so, I think the main thing I'd like to do organizationally is move the repo to a monorepo so we can have a setup like:
./<qunit> (existing files)
./test-packages/
./browser/
./amd/
./esm/
./script-import-map/
./bundled-esm/
...
./node
./esm/
./cjs/
...
as far as I know, only pnpm supports this type of monorepo where the top level is also a publishable package. thoughts?
from qunit.
@Krinkle is there a discord or some other chat platform where we'd be able to talk more synchronously about planning the future of the repo?
from qunit.
Related Issues (20)
- qunit: command not found HOT 2
- Great convergence effort/suggestion: Making QUnit proxy to node.js and deno testing APIs in these environments HOT 2
- Add DOM hook to allow links to be added after the Rerun link HOT 1
- Allow raw HTML as an assertion message HOT 1
- importing .css file using webpack css-loader/style-loader causes: TypeError: Unknown file extension ".css" HOT 2
- Improve assert.async Function to Handle Type Checking
- Qunit v2 has incorrectly configured exports HOT 4
- Drop support for IE9-IE10 HOT 3
- Can we move this repo to a monorepo so we can more accurately test different usage scenarios? HOT 1
- Drop support for node < 18? HOT 1
- Can we start a `next` branch so I can start PRing improvements? HOT 1
- Let simple array data in test.each() serve as automatic labels
- Facilitate "close to" number equal assertion HOT 3
- [Feature Request]: Allow more customization of how errors are handled (especially uncaughtrejection). HOT 1
- Web Test Runner and QUnit reporting problems HOT 9
- qunit cannot parse private functions and properties HOT 2
- Support multiple `module` parameters (QUnit.config.module array) HOT 2
- Unify qunitjs.com and api.qunitjs.com
- [QUESTION] How can I forcefully abort a testcase and advance to next in queue HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from qunit.