You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
short circuit, short-circuit, shortcircuit, essm, loader
Expected Behavior
The loader resolver should always pass the resolved URL to the next resolver (assuming it didn't already), without a shortcircuit. The loader should never shortcircuit anyway...
Actual Behavior
The lresolver/oader doesnot shortcircuit ever (I think...) and pass on its stuff to other loaders.
When adding NODE_OPTIONS='--loader ts-node/esm --loader testdouble I noticed that ts-node/esm was shortciruiting the resolution and so the testdouble resolver did not get a change to add some query parameters to the URL. When debugging this, I noticed that the load also shortcircuits. I also noticed that it does shortcircuiting due to "laziness" (your words, not mine!).
Replace the test script to be NODE_OPTIONS='--no-warnings --loader=testdouble --loader=ts-node/esm' ava test/**/*.test.ts.
In index.test.ts replace td.replaceEsm('../src/want-to-be-mocked.js') with td.replaceEsm('../src/want-to-be-mocked.ts').
Run npm test
You will see the test succeed, whereas it should have failed. The reason it failed is that the mocking did not happen because resolution shortcircuited testdouble.
A quick note about the short circuit logic: we always return the short circuit flag even when we don't short circuit. That flag doesn't trigger short-circuiting, it just tells node not to throw an error.
ts-node needs to ship a modified implementation of node's own default resolver, meaning it needs to come last in the chain. The resolution order should be:
import() -> your loader's resolve() -> ts-node's resolve() -> may use bundled, modified impl or may delegate to node's own default loader
Your loader should be able to call ts-node's resolver, then add query params to the response.
Search Terms
short circuit, short-circuit, shortcircuit, essm, loader
Expected Behavior
The loader resolver should always pass the resolved URL to the next resolver (assuming it didn't already), without a shortcircuit. The loader should never shortcircuit anyway...
Actual Behavior
The lresolver/oader doesnot shortcircuit ever (I think...) and pass on its stuff to other loaders.
Steps to reproduce the problem
The repo https://github.com/codan84/jest-ts-experiments/tree/ava-testdouble uses Ava, TS, and TestDouble, to write a simple test. So it uses two loaders:
ts-node/esm
andtestdouble
.When adding
NODE_OPTIONS='--loader ts-node/esm --loader testdouble
I noticed thatts-node/esm
was shortciruiting the resolution and so thetestdouble
resolver did not get a change to add some query parameters to the URL. When debugging this, I noticed that theload
also shortcircuits. I also noticed that it does shortcircuiting due to "laziness" (your words, not mine!).npm install
test
script to beNODE_OPTIONS='--no-warnings --loader=testdouble --loader=ts-node/esm' ava test/**/*.test.ts
.index.test.ts
replacetd.replaceEsm('../src/want-to-be-mocked.js')
withtd.replaceEsm('../src/want-to-be-mocked.ts')
.npm test
You will see the test succeed, whereas it should have failed. The reason it failed is that the mocking did not happen because resolution shortcircuited
testdouble
.Minimal reproduction
See https://github.com/codan84/jest-ts-experiments/tree/9dd8449734a2d08fd13dd1fc6b7dbb1459a1cdce and above
Specifications
The text was updated successfully, but these errors were encountered: