Verify sourcemaps before publishing

[justingrant]

Description

np should warn users when they try to publish a sourcemap that points to source files that don't exist in the package being published.

Is the feature request related to a problem?

Lately I've been wasting a lot of time chasing down libraries that publish broken sourcemaps to npm, where "broken" means that the sourcemap's sources array includes paths to source files that are either not published or are published to different locations than what's specified in the sourcemap. There are two basic cases:

• node_modules libraries that were published without source code. I've filed several PRs recently for various libraries to add their source. Most library authors have been happy to oblige. Example: Remove /source from .npmignore (for debugging with sourcemap) catamphetamine/libphonenumber-js#306
• monorepos or other cases where the sourcemap contains relative paths to source files that don't exist in the same locations after npm install that they did at build time. More details: map.sources converted to absolute paths + other changes webpack-contrib/source-map-loader#75 (comment)

It would be very helpful for the ecosystem if publishing tools like np showed warnings if a sourcemap points to non-existent files.

Possible solution

A solution could be something like this:

1. run npm pack to generate the tarball that would be published
2. unpack that tarball
3. Find all *.map files inside the package
4. Pull out the sources array from each sourcemap
5. For each path in sources, verify that that path (usually a relative path) is present in the package
6. If not present, show a warning, e.g. WARN: sourcemap ${sourcemap file} references ${filePath} which does not exist. Please publish source folders for debugging!

Alternatives

• Get npm publish to add this warning instead, which I think is the right long-term solution, but it might be helpful to first get it into a faster-evolving tool like np.

[SamVerschueren]

Would be as easy as creating a package verify-source-maps and run it in the prepublish hook?

I don't think this belongs to something like np to be honest. All the checks we do are git related or npm related, not code related. Things like this belongs in the test phase, not in the publish phase imo.

[sholladay]

Perhaps this should live in clinton. @SamVerschueren

[justingrant]

Would be as easy as creating a package verify-source-maps and run it in the prepublish hook?

The only problem with an opt-in solution is that most library authors probably don't know that checking sourcemaps is a thing they need to do. Having an opt-out solution would be more helpful for the ecosystem IMHO. But a prepublishOnly hook would be a reasonable first step to generate more awareness among maintainers that checking sourcemaps is something they should be doing.

[@SamVerschueren] I don't think this belongs to something like np to be honest. All the checks we do are git related or npm related, not code related. Things like this belongs in the test phase, not in the publish phase imo.

Even though they're code-related, the root cause is almost always NPM configuration: either a bad .npmignore or a bad files whitelist in package.json. Does that change your opinion? OK if no-- I'm new to np so am not familiar with what's in-scope vs. not.

@sholladay - Looking at the list of plugins for clinton, I agree that checking sourcemaps seems to fit in with other "is my package.json correct?" checks that clinton already has. BTW, I didn't know about clinton before-- thanks for pointing me at it. Looks like a useful tool!

[sholladay]

I also have a somewhat similar project named mop. Whereas clinton checks each project individually (as linters do), mop is an assistant that checks all of your projects at once. mop is designed for people who have dozens or hundreds of projects and want to make upgrades to many of them simultaneously or check "which projects have X", etc. So if a sourcemap rule were implemented, it could give you a list of projects on your machine that have broken sourcemaps. Then you could prioritize your work more easily.

[fregante]

I think this falls into #82, which also unfortunately hasn't received much interest. A sourcemap checker would not only have to check explicit files listed in package.json, but also scan every JS file and find their matching source map. Sounds too specific to be part of np before a tool like that even exists on its own.