Add minimal CLI tool to recover original source

[0xdevalias]

I know we can write our own, and that there are a couple of existing projects out there, but it would be cool if source-map contained a minimal CLI tool that allowed us to recover the original source of a file, given it's sourcemap'd file.

Eg. Given the following files:

• foo.js.map (sourcemap)
• foo.js (minified)

I would imagine being able to run it as follows (or similar):

npx source-map foo.js.map > foo.js.orig

See Also

• https://github.com/imyelo/source-map-cli/blob/master/bin/source-map
• https://github.com/gabmontes/source-map-cli

[0xdevalias]

Minimal naive example/PoC code:

Edit: Which I h ave also now uploaded to a PoC repo:

• https://github.com/0xdevalias/poc-source-map-cli/blob/main/index.js

#!/usr/bin/env node --experimental-modules

import { readFileSync } from 'fs';
import { SourceMapConsumer } from 'source-map'

// Get the sourcemap path from the command line arguments
const sourcemapPath = process.argv[2];

if (!sourcemapPath || sourcemapPath.trim() === '') {
  console.error('Error: sourceMapPath argument is missing or empty');
  console.error('Usage: node index.js <sourceMapPath>');
  process.exit(1);
}

// Load the sourcemap data
const sourcemapData = readFileSync(sourcemapPath, 'utf8');

// Process the sourcemap data to recover the original source code
const originalSources = await SourceMapConsumer.with(sourcemapData, null, async (consumer) => {
  console.error("Original Source URLs:", consumer.sources);

  return consumer.sources.reduce((acc, sourceUrl) => ({
    ...acc,
    [sourceUrl]: consumer.sourceContentFor(sourceUrl)
  }), {});
});

// Output the mapping of sourceUrls to original source as JSON
console.log(JSON.stringify(originalSources, null, 2));

{
  "name": "poc-source-map-cli",
  "version": "0.0.1",
  "description": "Recover the original code from a minified file and source map",
  "type": "module",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Glenn 'devalias' Grant (devalias.net)",
  "license": "MIT",
  "dependencies": {
    "source-map": "^0.7.4"
  }
}

[jkrems]

While it's true that it can be convenient to bundle a CLI with a utility library like this, in practice it often causes issues. The CLI tends to pull in quite a few unnecessary dependencies which bloats the dependency graph. In particular for source-map where multiple versions may be part of a larger dependency graph.

Having a separate official CLI package ("@source-map/cli") would be a lot easier to maintain, most likely.

[0xdevalias]

While it's true that it can be convenient to bundle a CLI with a utility library like this, in practice it often causes issues. The CLI tends to pull in quite a few unnecessary dependencies which bloats the dependency graph.

On one hand, I understand that.. but on the other, the above PoC doesn't add any extra dependencies..?

I'm not against it being a separate package though, would just be nice for it to exist.

[jkrems]

the above PoC doesn't add any extra dependencies..?

The tricky thing here is - it doesn't in the initial PoC. But then somebody comes around and says "this really should properly parse CLI arguments" and "wouldn't it be nice if it did syntax highlighting and has colors". All perfectly reasonable proposals for the CLI and would make it better - and it becomes very hard to retain the "zero deps" nature of it all.

The general trend over time for a package that ships a CLI is to either become very large or to do a painful split down the line (e.g. @babel/cli). So I'd be very cautious about making it a built-in feature, given that there's few (no?) downsides in creating a separate source map CLI package.

[0xdevalias]

Yeah ok, that definitely makes sense.