esm: delete preload mock test

[GeoffreyBooth]

Per #44710 (comment), this PR deletes a test that isn’t compatible with off-thread loaders; but more broadly, I think we’re likely to want to rethink the approach of globalPreload‘s sloppy scripts, rather than build on it. I’m not reverting the full PR that added this test, #39240, because we’re keeping parts of it. The off-thread PR will delete the undocumented setImportMetaCallback that that PR adds. More context: nodejs/loaders#124

cc @bmeck @nodejs/loaders

[bmeck]

This shouldn't be deleted without a plan forward. It was explicitly designed to work with off thread loaders so the claim it doesn't is concerning to hear and would be good to understand.

…

On Sat, Jan 28, 2023, 10:24 PM Geoffrey Booth ***@***.***> wrote: Per #44710 (comment) <#44710 (comment)>, this PR deletes a test that isn’t compatible with off-thread loaders; but more broadly, I think we’re likely to want to rethink the approach of globalPreload‘s sloppy scripts, rather than build on it. I’m not reverting the full PR that added this test, #39240 <#39240>, because we’re keeping parts of it. The off-thread PR will delete the undocumented setImportMetaCallback that that PR adds. cc @bmeck <https://github.com/bmeck> @nodejs/loaders <https://github.com/orgs/nodejs/teams/loaders> ------------------------------ You can view, comment on, or merge this pull request online at: #46402 Commit Summary - 11b88c2 <11b88c2> esm: delete preload mock test File Changes (2 files <https://github.com/nodejs/node/pull/46402/files>) - *D* test/es-module/test-esm-loader-mock.mjs <https://github.com/nodejs/node/pull/46402/files#diff-c7f1002d283d353145656887966dfbdd0ea26e13e398b21023d093c6248feadd> (45) - *D* test/fixtures/es-module-loaders/mock-loader.mjs <https://github.com/nodejs/node/pull/46402/files#diff-08a5d722c9df06780af1b452e4394133c678b11eee19530ef0bd871f4a8a2c2f> (249) Patch Links: - https://github.com/nodejs/node/pull/46402.patch - https://github.com/nodejs/node/pull/46402.diff — Reply to this email directly, view it on GitHub <#46402>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZJIY4YJQNUPGNBJ63FKDWUXWJLANCNFSM6AAAAAAUKATUUQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[GeoffreyBooth]

This shouldn’t be deleted without a plan forward.

This was discussed in nodejs/loaders#124 and #46220. Basically, test mocking can be achieved with just the port option in globalPreload, as that’s what Quibble is doing; and the test in #46220 tests port. So the use case of mocking for tests is handled with existing tests.

This test has a grander vision of what mocking for tests should look like, including mocking import.meta objects, but we can’t get it to work with the off-thread PR. We removed setImportMetaCallback a month ago from the off-thread PR. Since it was undocumented, my feeling was that it could always be re-added after the off-thread PR landed. But more broadly, I’m leaning against using the sloppy mode scripts of globalPreload as a way to inject what are essentially more hooks. I think we can remove the sloppy mode scripts entirely, now that we have --import; no one in nodejs/loaders#124 disputed that. To do so, we would need to find a different way to provide access to port, and to an equivalent to setImportMetaCallback if mocking import.meta objects is something we want to provide an API for.

[bmeck]

I can port the test to use a leaky global as well then. Removing this removes reference point I send to people about mocking direction for esm. Doesn't need a strict guideline to keep it frozen.

…

On Sun, Jan 29, 2023, 9:50 AM Geoffrey Booth ***@***.***> wrote: This shouldn’t be deleted without a plan forward. This was discussed in nodejs/loaders#124 <nodejs/loaders#124> and #46220 <#46220>. Basically, test mocking can be achieved with just the port option in globalPreload, as that’s what Quibble is doing; and the test in #46220 <#46220> tests port. So the use case of mocking for tests is handled with existing tests. This test has a grander vision of what mocking for tests should look like, including mocking import.meta objects, but we can’t get it to work with the off-thread PR. We removed setImportMetaCallback months ago from the off-thread PR. Since it was undocumented, my feeling was that it could always be re-added after the off-thread PR landed. But more broadly, I’m leaning against using the sloppy mode scripts of globalPreload as a way to inject what are essentially more hooks. I think we can remove the sloppy mode scripts entirely, now that we have --import; no one in nodejs/loaders#124 <nodejs/loaders#124> disputed that. To do so, we would need to find a different way to provide access to port, and to an equivalent to setImportMetaCallback if mocking import.meta objects is something we want to provide an API for. — Reply to this email directly, view it on GitHub <#46402 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZJIYSUKVOLY3CVDI5VSLWU2GUBANCNFSM6AAAAAAUKATUUQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[GeoffreyBooth]

I can port the test to use a leaky global as well then.

Can you do that as a commit on the branch for #44710? If you can refactor the test so that it passes on the off-thread branch, then sure, it can stay. At this point my top priority is landing that PR, as it’s holding up just about the entire Loaders API agenda, and I’m okay with removing things to make way for that PR landing (and those removed things can get added back later).

If you don’t have time soon to refactor the test on that branch, we can just land this removal PR and then a refactored version of the test can get added back in a later PR.

[bmeck]

I'm not blocking but likely wouldn't get to it in timely manner if it sounds like that pr would drastically alter things. As such removal of this is unfortunate since there isn't another mocking ref to ensure the feature in core is possible but acceptable.

…

On Sun, Jan 29, 2023, 11:39 AM James M Snell ***@***.***> wrote: ***@***.**** approved this pull request. — Reply to this email directly, view it on GitHub <#46402 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZJI6USNVLBYIIQCZ4D33WU2TNPANCNFSM6AAAAAAUKATUUQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[GeoffreyBooth]

As such removal of this is unfortunate since there isn’t another mocking ref to ensure the feature in core is possible but acceptable.

Sure, it would be nice if there was a test in core to validate that the mocking use case is possible; but I think such a test could be more minimal than this one, which goes beyond what I would consider the minimum acceptable mocking (such as setting up a fake import.meta for the mocked module). @giltayar in nodejs/loaders#124 (comment) seems very confident that as long as globalPreload port remains after the move to off-thread, Quibble will continue to be able to work. So I think we should be good, and having the test in core is a nice-to-have that can happen anytime. I asked him to contribute such a test when he found the time and he seemed willing.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/49240/

[aduh95]

At this point my top priority is landing that PR, as it’s holding up just about the entire Loaders API agenda, and I’m okay with removing things to make way for that PR landing (and those removed things can get added back later).

Another possibility would be to move that test to test/known_issues in the off-thread branch, that would let the CI be green while keeping the test in the repo.

[GeoffreyBooth]

Another possibility would be to move that test to test/known_issues in the off-thread branch, that would let the CI be green while keeping the test in the repo.

It’s not really a known issue in that we’re intentionally removing setImportMetaCallback. The test would be written for an API that no longer exists.

I suppose we could move it into known_issues and explain all this in a comment at the top of the test file, but is that really better? If we’re looking to create a TODO, we could open an issue on GitHub that we want a test for the mocking use case. That feels more likely to get noticed. Such an issue could link to this PR, to provide the old test as reference.

[nodejs-github-bot]

Landed in 938341a

[GeoffreyBooth]

@aduh95 I forgot to remove author ready/commit queue after your comment; should I have done so? Not sure if that was an outstanding question that wasn’t resolved.

[aduh95]

is that really better?

I might be wrong, but I think removing the file and adding it back later "reset" the git blame history, while renaming/moving the file would not. In that sense it would be better. Also if someone wants to work on the test, it's much easier if the code is still in the codebase rather than having to dig the PRs or the git history.

If the off-thread loader is not capable of mocking, that would be an issue, in that sense it's a known issue. setImportMetaCallback is an implementation detail.

I forgot to remove author ready/commit queue after your comment; should I have done so? Not sure if that was an outstanding question that wasn’t resolved.

I did not remove it myself, so no worries. I kinda regret not doing so, as now this test has been removed but the off-thread PR still has failing tests and still cannot land, so it could have waited longer, but anyway.