Jacob Smith

> Hello! I think one of the problems we will encounter, if we were to use esm, is mocking Module methods. As far as I know spec doesn't allow rewriting...

>> It is possible with a loader > I don't see how it's possible with provided link? It's not possible to redefine property on Module object. Ah, I think maybe...

> Another thing that I'm not sure I have seen before is the question of how to configure the loaders themselves. Since a loader is just an imported module, there...

> If loaders are spec-ed such that any termination of the loader thread is _guaranteed_ to crash the node process Yes, I would imagine node should crash. Perhaps @bmeck has...

At some point recently, we did discuss exposing `defaultGetFormat` and `defaultGetSource` in the `load` hook's arguments (instead of `defaultLoad`). Or do you mean you'd want it exposed from some builtin...

I think there might be 2 separate issues here, the second being: > ```ts > import { foo } from "./foo.ts" > ``` > And then just implement the loader...

I'm wondering if `tsconfig.paths` and `tsconfig.references` need support as it seems they'll be obsolete with typescript supporting workspaces and subpaths / module resolution (currently in beta).

Ah, sorry, I meant * `tsconfig.paths` ↔ `packageJson.imports` (subpath) * `tsconfig.references` ↔ `packageJson.workspaces` I have not used `tsconfig.references`, but they look exactly like `packageJson.workspaces` and a quick read of [the...

I think the reason we did that for `resolve` and `load` is because their innards are substantially different due to the middleware vs iterative design. If that would be more...

> As far as I know, the `resolve` return value must be an existing file, which isn't the case here. @arcanis that is not correct 🙂 See [test-esm-loader.mjs → virtual...