Suggestion: improve default source map behaviour for Node users

[OliverJAsh]

Feature request

What is the expected behavior?

Given:

./package.json (all latest versions):

{
  "dependencies": {
    "source-map-support": "^0.5.13",
    "webpack": "^4.39.2",
    "webpack-cli": "^3.3.7"
  }
}

./webpack.config.js:

const pathHelpers = require("path");

// Expect `__dirname` to be `/config/target/`.
const ROOT_PATH = __dirname;
const TARGET_PATH = pathHelpers.join(ROOT_PATH, "./target/");
const SRC_PATH = pathHelpers.join(ROOT_PATH, "./src/");

const ENTRY_FILENAME = "index.js";
const OUTPUT_FILENAME = "index.js";

const config = {
  mode: "development",
  target: "node",
  devtool: "source-map",
  entry: pathHelpers.resolve(SRC_PATH, ENTRY_FILENAME),
  output: {
    path: TARGET_PATH,
    filename: OUTPUT_FILENAME
  }
};

module.exports = config;

./src/index.js (entry file):

const fn = () => {
  throw new Error("foo");
};

fn();

When running:

webpack
node --require source-map-support/register ./target/index.js

The error stack trace looks like this:

/Users/oliverash/Development/webpack-source-map-test/target/webpack:/src/index.js:2
    throw new Error('foo')
^
Error: foo
    at fn (/Users/oliverash/Development/webpack-source-map-test/target/webpack:/src/index.js:2:1)

Observe how the path to the source file where the error originated is resolved against the source map, but only partially so. This makes it difficult to interact with the stack trace. E.g. in iTerm, it's usually possibly to Command + click a path to open it, but this is not possible here because the path is invalid. Ideally the original file path would be shown.

IIUC, we can fix this using devtoolModuleFilenameTemplate/moduleFilenameTemplate:

   output: {
     path: TARGET_PATH,
     filename: OUTPUT_FILENAME,
+    devtoolModuleFilenameTemplate: "[absolute-resource-path]"
   }

Now the error stack trace looks like this:

/Users/oliverash/Development/webpack-source-map-test/src/index.js:2
    throw new Error('foo')
^
Error: foo
    at fn (/Users/oliverash/Development/webpack-source-map-test/src/index.js:2:1)

However, I would like to suggest that we make this behaviour the default when using webpack to build code that will be ran by Node (i.e. when target: 'node' as in this example).

Secondly, when using eval-source-map instead of source-map (used above), devtoolModuleFilenameTemplate does not help. The error stack trace always looks like this:

webpack-internal:///./src/index.js:2
    throw new Error('foo')
    ^

Error: foo
    at fn (webpack-internal:///./src/index.js:2:11)

Again, this path is difficult to interact with—ideally the original file path would be shown. What is the recommended fix in this case?

Are you willing to work on this yourself?
yes

[webpack-bot]

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[alexander-akait]

Bump

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

[OliverJAsh]

Should this be reopened again @evilebottnawi?

[bcoe]

It was answered a lot of time... Do you try using search?

@evilebottnawi I did perform a search, specifically searching for the webpack:// path prefix and sourceRoot (which is a field documented by the Source Map v3 spec, that could potentially help with source map handling) -- this thread happened to not come up.

My hope is that someone from the project can provide some direction to the Node.js project, so that we can make sure our source-map handling works well for webpack.

[bcoe]

However, I would like to suggest that we make this behaviour the default when using webpack to build code that will be ran by Node (i.e. when target: 'node' as in this example).

I like @OliverJAsh's recommendation that when --node is set, the path would omit the webpack:// prefix, and emit a file system path 👍

When I look at the source maps generated by TypeScript:

"sources":["../../../src/v1/secret_manager_service_client.ts"]

and rollup:

"sources":["../lib/yerror.ts","../lib/utils/apply-extends.ts","../lib/parse-command.ts","../lib/argsert.ts"]

Both opt to use relative paths in the sources array. To me, this seems like the idea behavior, as:

• folks can choose to resolve the absolute path if they wish.
• the source map doesn't have information about the local runtime baked into it.

[sokra]

A SourceUrl like webpack:///./index.js is an absolute URL and one should not try to resolve it. That's how it's specced. But nonetheless one can configure different patterns for the sources in the SourceMap with output.devtoolModuleFilename. I would recommend to keep the webpack:// prefix as sources in SourceMap might not match sources on disk at this location. The prefix is a good indicator that this is a webpack processed source.

[bcoe]

A SourceUrl like webpack:///./index.js is an absolute URL and one should not try to resolve it.

@sokra so, you'd advocate that when handling source maps for stack traces in Node.js, we do something like this:

Error: foo
    at fn (/Users/oliverash/Development/webpack-source-map-test/src/index.js:2:1)
       -> webpack:///./index.js:33:5

☝️ if a URI of this format is observed.

[sokra]

Yes

[alexander-akait]

Let's close in favor #3603, I think we can improve it for node users or as minimum improve docs how to chive it, it doesn't mean we don't work on it, it means we want to improve it and union issues because the issue related to webpack:// too and always take account edge cases