ESM entry?
dy opened this issue · comments
Atm the package can't be consumed in browser via direct ESM/import-maps.
Is there a point in adding ESM entry?
There probably is more work necessary to make this run in browsers, for example this relies on async_hook and process events currently. @thlorenz asked about browser compatibility too.
I think a rewrite for browsers could be the way to go. Not sure yet.
Hi, is there still a plan to make node:test run on the browser?
Came here after being redirected from Isomorphic Test Runner issue I opened on main node repo:
What is the problem this feature will solve?
Currently I'm developing a library that runs both on node.js and on the browser and I would like to use node.js native test runner. However, I won't be able to use it because it only runs on node.js.
What alternatives have you considered?
Mocha: runs on the browser and node.js, but it is not TAP compatible. Also, depends on changing global variables.
Jest: runs on the browser and node.js, but it is not TAP compatible. Also, depends on changing global variables.
Tape: runs on the browser and node.js, but it has not the same authority as node.js test runner.
Ava: runs on node.js, but not on the browser (experimental).
How could node:test ever run in a browser? It uses the filesystem extensively.
How could
node:testever run in a browser? It uses the filesystem extensively.
I believe that the use of files is just to discover the tests (ex: require all *.test.js files). Once listed, the test engine has no IO dependencies (I think).
If this test discover part is isolated, the test runner would be the same for the browser and for node.js
@dalssoft there are other hurdles besides the file system. Just off the top of my head:
- The test runner reaches into C++ code to obtain the location of the tests.
- It also relies on Node's
async_hooksAPI. - Node streams are used for reporters. This could be handled in the browser with a polyfill.
There is also a big non-technical problem: IMO people are unlikely to do the work on this module. It was mainly created so that people could use the test runner on older versions of Node. Now that those versions of EOL, there isn't a lot of activity in this repo (note the last commit was over 8 months ago at this point).
Thanks @cjihrig for the reply.
I don't know the current flow or the history of the project, but given the information I obtained today, I have some questions and some ideas.
First, I believe that the test package could be the standard for javascript testing if it ran in the browser (with the necessary changes) and came as default in nodejs (as it is today). The only difference would be that this repository would be the source of truth.
From what I understand, with the correct refactoring, the current dependencies (C++, async_hooks, etc.) could be replaced by pure js and without platform dependencies. I can't see why it should be different or what advantages these dependencies bring to the project. The testing APIs appear to be simple.
First, I believe that the test package could be the standard for javascript testing if it ran in the browser
I don't think we have any reason to believe that. Node's test runner, by design, is more minimalistic than a lot of userland alternatives.
The only difference would be that this repository would be the source of truth.
I would personally be opposed to making this change. I really dislike when Node core vendors in JavaScript projects for public facing APIs.
From what I understand, with the correct refactoring, the current dependencies (C++, async_hooks, etc.) could be replaced by pure js and without platform dependencies. I can't see why it should be different or what advantages these dependencies bring to the project. The testing APIs appear to be simple.
The APIs are simple, but there is a lot under the hood. We would definitely need a concrete plan beyond "just refactor them away." Are you volunteering?
Node's test runner, by design, is more minimalistic than a lot of userland alternatives.
Sure, but it can be extended by external packages (userland). Actually that is something I'm playing with right now.
when Node core vendors in JavaScript projects for public facing APIs
Well, but if we just extract a piece of code from node and make it work stand alone it should not be seem as a vendors lib.
but there is a lot under the hood
That's the part I'm really clueless. Why C++, async_hooks, etc. are being used on such simple API. What are the requirements to make use of it? Is there a killer feature to justify using this technologies? Btw, last time I checked this is the introduction for async_hooks: "[Stability: 1] - Experimental. Please migrate away from this API, if you can." [1]
Are you volunteering?
If (1) the assumptions that just pure js would make it work is correct, (2) this ideia of isomorphic test runner is valid, worth the effort and accepted by this community and (3) ideally if I have some guidance to navigate the code, I think I could take a look and contribute on this effort...
when Node core vendors in JavaScript projects for public facing APIs
Well, but if we just extract a piece of code from node and make it work stand alone it should not be seem as a vendors lib.
No matter how we turn it, having two repos increases the maintenance burden, e.g setting up testing with the latest main and on all the platforms Node.js supports is really unpractical, and that could lead to some issues being unnoticed until the vendored version gets updated on the nodejs/node repo (that happens every once in a while with the other deps that we vendor).
If (1) the assumptions that just pure js would make it work is correct, (2) this ideia of isomorphic test runner is valid, worth the effort and accepted by this community and (3) ideally if I have some guidance to navigate the code, I think I could take a look and contribute on this effort...
If you're able to refactor the code so it runs on browsers and all the tests still pass, tbh that would be pretty cool, and I don't see why it would be rejected from here. I can't promise if it would make it to node core, that'll depend on what are the tradeoffs you have to make.
As Colin said, this repo has kind of lost its meaning now that node:test is available on all non-EOL release lines of Node.js, so if you have the time to make it something else, and you are willing to keep maintaining it, that can certainly happen. Otherwise, it's probably time we archive this repo, and deprecate the npm package (both actions are easy to undone if we change our minds in the future).