Skip to content
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

Get list of mocked modules #519

Closed
JakobJingleheimer opened this issue Oct 17, 2023 · 7 comments · Fixed by #521
Closed

Get list of mocked modules #519

JakobJingleheimer opened this issue Oct 17, 2023 · 7 comments · Fixed by #521

Comments

@JakobJingleheimer
Copy link
Contributor

I use testdouble pretty extensively, and for each test run, I'd like to list which modules have been replaced (via replaceEsm). I don't see anything relevant in the docs or exported from td.

PS Love this lib

@searls
Copy link
Member

searls commented Oct 17, 2023

This may be reachable without modification if you want to investigate. I'd look for references to these values as a starting point, since they're what gets reset in the ESM loader. (Module replacement is handled by another module we own called quibble.)

I'd be open to a PR to Quibble and/or testdouble.js itself that provided this information if it's not reachable any other way, because I agree this would be interesting to know from a debugging perspective. However, I've been out of this codebase so long I don't know how much help I'd be. CC/ @giltayar since he was in the quibble code most recently

@JakobJingleheimer
Copy link
Contributor Author

JakobJingleheimer commented Oct 17, 2023

Hmm, it looks like from the code you cited that it does not expose this (that code handles only registration and de-registration of module mocks).

On a related note: I noticed that is using globalPreload, which will be removed in node v21 (which is due any day). I believe Gil is aware, but juuust in case.

EDIT: By "any day", I apparently meant today: https://nodejs.org/en/blog/release/v21.0.0

@giltayar
Copy link
Contributor

giltayar commented Oct 17, 2023

On a related note: I noticed that is using globalPreload, which will be removed in node v21 (which is due any day). I believe Gil is aware, but juuust in case.

The current code is an archeological dig that shows all the layers of how to implement ESM Loaders, from the first to the last 😁. We currently support Node 16, 18, and 20 (with the new "register"). Which is why we have both globalPreload and initialize.

I plan on removing all these archeological layers and cleaning up the code once 18 disappears from the map. Till then, globalPreload should stay.

@giltayar
Copy link
Contributor

giltayar commented Oct 17, 2023

I use testdouble pretty extensively, and for each test run, I'd like to list which modules have been replaced (via replaceEsm). I don't see anything relevant in the docs or exported from td.

We definitely have the information in quibble (quibble is the low-level library that actually implements the mocking). It's just not exported. It's not trivial, because of the move to off-thread, because the information is in the off-thread loader, but nothing really difficult to work with - a bit of message passing and you're done.

Note that the list of modules will not include their original name (e.g. lodash), but rather the final resolved URL (e.g. file:///.../node_modules/lodash/index.js).

I can try and do something, but just as a curiosity: why would you need this list?

@JakobJingleheimer
Copy link
Contributor Author

For my immediate need: I have a globally mocked module (which otherwise accesses indexeddb that doesn't exist in node). The module is mocked via mocha's global before/each. In a particular test, it throws that indexeddb doesn't exist, which means something is failing. I want to confirm that testdouble doesn't think it's mocked and hopefully pinpoint why it is not mocked. I suspect it's due to td.reset() in other tests resetting the global mocks (which should never be reset—but the global beforeEach should put them back).

@giltayar
Copy link
Contributor

So... For troubleshooting failed tests. Makes a lot of sense.

@JakobJingleheimer
Copy link
Contributor Author

By the way, it's related to problems caused by td.reset() detailed here: #520

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants