Andrew Bradley

I have made this fix and published a forked version to `@cspotcode/opendocumenter`: https://www.npmjs.com/package/@cspotcode/opendocumenter

Should we leave this open since the issue is still not fixed?

I have made this fix and published a forked version to `@cspotcode/opendocumenter`: https://www.npmjs.com/package/@cspotcode/opendocumenter

I think so, but I'm not sure. Where should I look to find more information? Is there a nodejs/node ticket, or a search query I can use to find it?...

Currently, my understanding of webpack's behavior is: - find `webpack.config.*` - based on file extension and consulting the mappings in [`interpret`](https://www.npmjs.com/package/interpret), webpack loads `ts-node/register` - webpack attempts to `import('./webpack.config.ts')` EDIT...

Ok, agreed it is worth investigating because the webpack use-case applies to other tools, and I believe it is in a blind spot being missed by current design discussions. gulp...

What's the scope of the loader's influence? If a package's entry-point is loaded using the loader, and that package attempts to dynamically or statically `import` a path that the loader...

> there are no real “scope” boundaries (everywhere is fair game). That's good to hear. It means that a package can declare a configurable pass-through loader, then make special requests...

My goal here is that I believe phase 2 of loaders needs to consider this use-case, and the hack I've proposed above is simply one way we can achieve it...

Ok, sounds good. I created #8 to start, but I can move it to a gist or anywhere else if you want. I am definitely interested but I don't want...