node_modules with source-map but without sources break sorcery

[Markus Wolf]

If there is a node_module with a source-map which does not include its sources like web-animations-js sorcery fails while trying to read the source-file.
Would it be an acceptable fallback to create a stub source containging something like this?

// no source file for <path> found

[Anil Kulkarni]

I have a similar same issue, but for my dependency (redux-immutable), it had a sourcemap with inline sourceContent, just pointed at the wrong sourceRoot.

https://github.com/Rich-Harris/sorcery/compare/master...textioHQ:topic-sourcerootery?expand=1

I'm willing to put in the work to implement the following, but want to agree on the design etc. so that the fork will eventually mainline :-)

@Rich-Harris How do you feel about the following proposal:

1. Sorcery ends up with two special directories: process.cwd(), and the directory of the top-level file passed into sorcery.
2. For these special directories, sorcery will do extra work to try to make source maps work. Some of the proposals I have include:

• Don't throw if resolving a dependency inside a node_modules/* underneath one of these special directories
• Try to fix up the sourceRoot of any node_modules dependency to point to that folder
• Try to fix up the sourceRoot as if it were relative to the difference between the CWD and the the current file
• Always try to fix up the sources name EVEN IF the sourceContent is present.

To do some of these things means a couple of design questions need to be thought through first:
What should the API layer look like? Do we want to start passing in more options into sorcery to control these heuristics?
How should the code flow be re-designed? Currently any error in loading a file just throws an FS exception and that propogates all the way outside sorcery to the caller. Do we want to take this time to reconsider the error case API for outside callers? What about inside of sorcery? Doing a generic try/catch seems sub-optimal.

Ideally these heuristics should also not pollute the core code as well - it would be better to layer these strategies as a driver off to the side so you can compose and test them.

If you take a look at the hack I put in, you can see a concrete example of what adding in new strategies looks like without a major refactoring of the code.