Support source maps with no file existing on disk

[rjgotten]

Source map destination files do not need to exist on disk. Source text can be embedded within the map file instead.

Current codecs all check for validity of a file on disk.
While it's possible to create 'unchecked' variants of these, later on inside the loader's own processing we arrive at another file check:

adjust-sourcemap-loader/lib/process/decode-sources-with.js

Lines 51 to 54 in b2c8bf2

	// non-existant file implies error
	else if (!fs.existsSync(decoded) || !fs.statSync(decoded).isFile()) {
	return getNamedError('Cannot find file at absolute path:\n' + decoded);
	}

This we cannot resolve from user-land. It basically makes the entire loader useless if you're dealing with libraries that use embedded source maps.

[bholloway]

Okay @rjgotten I think we can accomodate. You have some well structured points so I will just reply.

"possible to create 'unchecked' variants of these [codecs]"

I think you are on the right track. Trying to infer how the source-map sources are constructed really requires project knowledge.

Originally I went for the general solution but it is only reliable if we check the files exist.

"Current codecs all check for validity of a file on disk."

Where a file check is necessary I think it makes sense to restrict it to the codec. I would need to survey myself.

🤔 This would probably be the best "separation of concerns" but maybe a risky change without tests. I would need to look properly.

Failing that I could add a flag that allows you to opt-out of the tests. There is precedent with the abstract flag. So maybe a force flag?

Let me know what your preference is.

[rjgotten]

Maybe something slightly more intelligent: skip only the verification of whether files exist on disk, provided the source map already has the file content embedded as a sourcesContent array.

Ofcourse, a force flag is easier to implement. But imho not quite as nice.
And potentially more dangerous to end up with an invalid map.

[bholloway]

@rjgotten your suggestion is interesting but I suspect unsuitable - It is not always possible to opt-out of sourcesContent. In my own use case sourcesContent exists but the actual sources also need to exist so I can delete the sourcesContent downstream.

Fundamentally I think that most of the codecs only work if the files are present. Otherwise there is no basis to differentiate them.

I think we can remove the additional check you originally highlighted. I am thinking it was probably originally done to validate the output of custom codecs. But as you have found it is over-restrictive. I am inclined to just remove it as a breaking change and publish a @next dist-tag for you to play with.

[bholloway]

@rjgotten looking at the code just now I recall the concept of an abstract codec.

This is usually used for sources such as the webpack bootstrap that can be recognised but will not be amended in any way.

If you don't intend to amend the sources in question then you could just prepend a codec that is abstract: true and simple returns decode(): true for just those paths. This will ensure they are retained as is.

However if you intend to adjust these sources then we will need to make a change as discussed.

[bholloway]

@rjgotten please try adjust-sourcemap-loader@next and use the custom resolvers as you first implied.

[bholloway]

@rjgotten should we release this? how did it go?

[rjgotten]

I have not yet been able to revisit the part of the project in question, where I needed to apply this.
Sorry. :(

[bholloway]

No rush @rjgotten. Let me know when you do.

[bholloway]

I'm going to release this on risk @rjgotten 🤞

[bholloway]

Should be fixed by #6 🤞