Andrew Bradley

> We've talked about doing that for at least one of them already; @cspotcode @jonaskello do you need all of them or just a subset? I will have to think...

Currently our duplicated `resolve` loader also needs to read `package.json` since it needs access to other fields like `main` and `exports`. It might be worthwhile exposing the `package.json` cache for...

> This is all hypothetical, since Node itself doesn’t load any modules over HTTP; that would be up to however you design your HTTP loader. Specifically I'm thinking about two...

Are you referring to one of the `*Host` interface declarations as an example? Or an implementation of TypeScript's `System`, which declares every bit of functionality that the compiler attempts to...

`tsconfig.references` tells the TS compiler to do `outDir` -> `rootDir` mappings for additional tsconfigs. I think, but I'm not sure, that `outDir` -> `rootDir` resolution is unnecessary within a single-tsconfig...

It sounds like we're describing sub-hooks of `resolve`. And yeah, if node doesn't implement the sub-hooks, then they'll need to be implemented in user-space. So we'll need some sort of...

Thinking out loud about all the potential use-cases for loaders being discussed: Do any of the http loader use-cases currently assume the ability to make http requests within `resolve()`? It's...

Oh right, something like the unpkg example is what I keep mentally returning to: a loader with resolution logic that requires looking up files / directories / URLs first, such...

Users of npm.im/pwsh reported this bug recently: https://github.com/cspotcode/npm-pwsh/issues/18

Can add to the list of package authors: esmock I wonder, does it make sense for the loaders team to have a thread somewhere which can be subscribed to for...