A feature request for logs to show the original source code from the embedded source map

[wfleming]

I'm in the process of porting a very old & crufty JS app with a very old & crufty build process to esbuild. The app uses a very old Redux version, and thus uses function decorators for @connect on React components. I wrote a small onLoad plugin to transform the decorators with babel (source) so I can process these files. This is working well, but when esbuild emits warnings on these files it does so using the line numbers of the transformed source, which don't match the original source.

For example, the following toy file:

import React from 'react'
import {connect} from 'react-redux'

@connect(state => ({a: state.a, b: state.b, a: state.a}))
class FooComponent extends Component {
  render() {
    return <ul>
      <li>a: {this.props.a}</li>
      <li>a: {this.props.b}}</li>
    </ul>
  }
}

Emits these warnings:

▲ [WARNING] Duplicate key "a" in object literal [duplicate-object-key]

    foo.js:7:2:
      7 │   a: state.a
        ╵   ^

  The original key "a" is here:

    foo.js:5:2:
      5 │   a: state.a,
        ╵   ^

▲ [WARNING] The character "}" is not valid inside a JSX element

    foo.js:12:27:
      12 │       <li>a: {this.props.b}}</li>
         │                            ^
         ╵                            {'}'}

  Did you mean to escape it as "{'}'}" instead?

The duplicate keys are in fact both on line 4, and the extra } is on line 9. I've confirmed the reported lines match the output from babel, though. The delta is tiny for this toy example, but in real files it's often different by dozens of lines, making it trickier to identify where the issue is.

I am including inline sourcemaps in the transformed source generated by babel, and these inline sourcemaps seem to be getting translated correctly for esbuild's sourcemaps emitted along with the bundles, so I think the sourcemaps in the transformed source are correct. (This is an amazing feature, btw, I genuinely wasn't expecting sourcemaps for transformed source to "just work" in the browser when I spiked out the esbuild pipeline, so thank you for this functionality.)

While the warnings from esbuild are still useful this way and it just takes a bit of grepping to figure out where the issue really is, it would be great if these reports also paid attention to the inline sourcemap. Was not doing this an intentional decision (e.g. because the transformed source might include an issue the original source did not), or is this supposed to work and I'm doing something wrong in my plugin, or something else?

Thanks for your time, and thanks for esbuild. Building out our build pipeline with it has been a breath of fresh air compared to other bundlers I've worked with: it feels like a great, well designed library which is much more pleasant than the giant-ball-of-config a lot of bundlers end up being.

[hyrious]

Just put the corresponding Source Map visualization here.

This is the code generated by babel:

var _dec, _class;
import React from "react";
import { connect } from "react-redux";
let FooComponent = (_dec = connect(state => ({
  a: state.a,   // <- 5
  b: state.b,
  a: state.a    // <- 7
})), _dec(_class = class FooComponent extends Component {
  render() {
    return <ul>
        <li>a: {this.props.a}</li>
        <li>a: {this.props.b}}</li>    // <- 12
      </ul>;
  }
}) || _class);
console.log(FooComponent);

As you can see, the line numbers in warning messages are reporting from the generated code location instead of the source location.

[evanw]

Was not doing this an intentional decision (e.g. because the transformed source might include an issue the original source did not)

Yes, this is one reason. Another reason is that it would take extra effort to have something else happen, and another reason is that source maps are a sparse mapping so there isn't necessarily a mapping in the source map for the location of every error (which could lead to very confusing errors). Note that embedded source mappings are always respected for the final output source map, just not with error reports.

I can see the argument for reporting an error in the original source code in addition to what esbuild already does. I'll consider this issue a feature request for expanding the logging system to also add a line from the original source code in these cases. This would only be done if the source content is present (source maps don't necessarily include it) and also possibly only if there is a mapping present in the source map at that exact location.

Note to self: this log augmentation can't be done in the parser when the errors are produced because that's behind a cache keyed on the file contents, and the source map may be a link to an external file not behind the cache. So this processing would have to happen in the bundler, not the parser (and should obviously only be done when the parser generates log messages that need this processing).