webpack: Source Maps don't work on Chrome

I just conducted a little experiment, which might be of interest here.

Chrome 57, webpack 2.3.3, babel-core 6.24.1, babel-loader 6.4.1, vue-loader 11.3.4

	Line numbers	File names	File names mappable	Breakpoints	Proper breakpoints	Breakpoints trigger
No source maps	Refer to the bundle	:white_check_mark:	:white_check_mark:	:white_check_mark:
eval & cheap-source-map	:x:	:white_check_mark:	:x:	:white_check_mark:	:white_check_mark:	:white_check_mark:
cheap-eval-source-map	:x:	:white_check_mark:	:x:	:white_check_mark:	:white_check_mark:	:x:
cheap-module-eval-source-map	:white_check_mark:	:white_check_mark:	:x:	:white_check_mark:	:white_check_mark:	:x:
cheap-module-source-map & cheap-module-inline-source-map :small_red_triangle: :tada:	:white_check_mark:	:white_check_mark:	:white_check_mark:	:white_check_mark:	:white_check_mark:	:white_check_mark:
eval-source-map	:white_check_mark:	:white_check_mark:	:x:	:white_check_mark:	:x:	:x:
source-map	:white_check_mark:	:white_check_mark:	:white_check_mark:	:white_check_mark:	:x: 1	:white_check_mark: 1
nosources-source-map	:white_check_mark: 2	:white_check_mark: 2	:white_check_mark:	:x:	:x:	:x:
inline-source-map :small_red_triangle:	:white_check_mark:	:white_check_mark:	:white_check_mark:	:white_check_mark:	:x: 1	:white_check_mark: 1

Notes:

• Line numbers = whether the line numbers are correct
• File names = whether the file names are correct
• File names mappable = Sometimes the correct file name is shown, but with a suffix (foo.js?a1b2:123). In this case Chrome cannot map the file to the filesystem so it cannot be edited in the Developer Tools. Note: Currently, when I set up a mapping, I can no longer use breakpoints, I haven’t found out the reason yet.
• Breakpoints = whether breakpoints can be set at all
• Proper breakpoints = sometimes breakpoints can be set, but only in certain lines, then this is marked false
• Breakpoints trigger = whether the set breakpoints actually trigger

¹ Breakpoints cannot be set properly, but set breakpoints do trigger. ² Of course the source only shows after the file has been mapped, but then line number and file name are shown correctly. 🔺 The inline-source-map and cheap-module-inline-source-map styles are not listed in this table.

I have this issue on OSX. Also, https://phabricator.babeljs.io/T6842

I can confirm the issue is still there with webpack 2.1.0-beta.25

@sokra thinks you don’t need to edit your original files in browser:

module source != file content in most cases anyway

Anyway 😉

https://github.com/webpack/webpack/issues/559#issuecomment-60888621

I don’t think that webpack 4 is going to solve any actual problems you need to solve:

• CSS component dependencies with ExtractText plugin without module code inserted for each CSS import (you can ignore it now though).
• Debuggable and editable minified code (I’m really stuck!).
• Stable chunk hashes OOB (luckily, solved by the md5 plugin).

So, this issue is most important one. Why webpack adds 4 newlines and a footer comments to each module even when no loaders are enabled? It’s ES8 era, and we no more need Babel.

Luckily, @sokra’s comment has an advice on how to solve the problem with “real” file paths to make debugging and editing a smooth experience, as it should be.

By the way, if you use transpilation, from TypeScript, CoffeeScript, etc., keep in mind that your transpiler CAN supply perfectly consumable source map to webpack, so it HAS TO refer to your original TypeScript file instead of the intermediate transpiled one. Which allows to put breakpoints right into your original source code - in devtools - and even edit it right there.

Many stages of very correct source map transformations must happen in order to preserve that smooth developer experience.

Unfortunately, webpack doesn’t embrace convention over configuration, and breaks your config file every major release, so all this source map transformation pipeline seems to be broken almost all the time.

For sure, it was working for me 2 years ago allowing to smoothly debug my Babel-transpiled ES2015 sources in Chrome, but now it’s the era of disabling all of the transpilation, and things are broken again.

I’m very, super sad and incredibly frustrated that the awesome and pretty fast tool which practically all web developers have to use every day (we just have no other production-ready choice able to solve a lot of problems), is appears to be broken almost all the time.

The amount of time I’ve spent since the first npm i -D webpack is unacceptable, and much more than the time I actually spent developing web applications.

I think, the webpack team should reconsider their over-engineering priorities with the new CSS modules approach, and focus on webpack@5 to get rid of all configurable plugins to support debuggable and editable minified outputs and CSS imports with extracted text OOB.

IMO. Don’t be hard on me. The npm team already had issues with my sarcastic impatience, but I have no idea how to express your opinion otherwise. Note that I’m not offering to “fire” @sokra LOL

Happy 2018!

cheap-module-eval-source-map broken here. Exceptions are pointing to file ?d41d, whose contents are:

undefined


/** WEBPACK FOOTER **
 ** 
 **/

Changing to any devtool mode that lacks the “module” keyword does work as expected.

macOS 10.11.6, Chrome 53, webpack 1.13.2, webpack-dev-server 1.15.1

+1

Since I received negative feedbacks I clarify my +1: using cheap-module-eval-source-map in chrome 53 on macOS 10.11.5 and using webpack 1.13.2 I get the same js contents as @brianblakely:

undefined


/** WEBPACK FOOTER **
 ** 
 **/

Had same problem with my source map either working or being not correct line wise. But using:

new webpack.SourceMapDevToolPlugin({
     filename: '[file].map'
})

have solved my problems instead of using devtool: ‘source-map’. Just a heads up if someone lands the same issues.

Configuring with this devtool: 'inline-module-source-map' into webpack fixed my issues where debugger wasn’t acessing the current context. I’m running with webpack-dev-server and webpack 4

This issue design choice was confirmed as intentional by @ChromeDevTools in this thread: https://twitter.com/dan_abramov/status/960324134734573569

There’s a lot of talk, but this was the best I could get out of them:

Ah, I see. Yeah, at the moment the explicit mappings are gone from Workspaces 2. I’m hearing a lot of feedback similar to yours, though, and we’re exploring our options — kayce

There’s 130 people subscribed to this thread, I think this issue could use a bit more visibility. I really don’t like to see Chrome enforcing certain user/dev workflows like this.

+1

inline-source-map only works in Chrome (60.0.3112.113) the first time page loaded. Works well in FireFox and Chrome Canary.

eval-cheap-module-source-map works fine in all three browsers, but disabled adding breakpoints.

I did some further tests, It looks like eval-*** options will always work, but disabled adding breakpoints, while others only works the first time when page loaded in Chrome.

To me, it more likes a Chrome bug, because it is solved in Canary. I would use inline-source-map at this point, and use ALT + R to refresh the dev tool in Chrome to make the source map works.

I’m still seeing the issue in Canary 53.0.2777.0 on OS X. Changing devtool: '#eval-source-map' to devtool: '#inline-source-map' fixes it for me. So it doesn’t look fixed.

If you are not using canary, use @xuefengwang’s suggestion and change source-map to inline-source-map in your webpack config.

It’s fixed (and confirmed working for me) in Canary now https://bugs.chromium.org/p/chromium/issues/detail?id=611328#c21

Why is this closed? It is clearly still an issue.

After pulling my hair for 2hs I got it working on

webpack: 3.5.5 Javascript ES6 Node: v8.2.1 Chrome: 60.0.3112.101 (symfony encore 0.14)

using devtool: 'cheap-module-eval-source-map'

Yes I have the issue on OSX too.

There’s actually two separate issues.

One is that non-inline, non-eval source maps didn’t work in Chrome. That’s since fixed in Chrome 52.

The other is that breakpoints on initial code execution don’t work with eval source maps in at least Chrome and maybe other browsers. That one is still outstanding, but it’s a different problem.

This does not work for me in Chrome 62, regardless of what I set devtool as.

I can verify that the .map files are indeed being generated and have the proper names (they are also properly referenced from the JS files they belong to), but when I try to open the files in DevTools, nothing gets loaded.

It’s been a while since I last visited this issue, but I am almost certain it kind of worked for med in Chrome 57.

If you had issues with cheap-module-source-map, try updating to Webpack 1.14.0. It included https://github.com/webpack/source-list-map/pull/2 which fixed completely broken sourcemaps for me.

Also here on OSX and same Chrome as above, breakpoints are not breaking with eval-cheap-module-source-map. All works with source-map but of course with a much slower compilation.

“#inline-source-map” or “#source-map” made the breakpoint work on OSX Chrome, build/rebuild speed is slower though.

I’ve found a solution. Use plugin new webpack.SourceMapDevToolPlugin() instead of devtool param (this param must be removed from the configuration).

I tested all options with following setup:

• win32
• webpack-dev-server 2.2.0-rc.0
• chrome 55.0.2883.87
• source-list-map 0.1.7

The results are:

• devtool = ‘source-map’; // works
• devtool = ‘eval-source-map’; // fails
• devtool = ‘cheap-module-source-map’; // works but misses line numbers
• devtool = ‘cheap-module-eval-source-map’; // fails
• devtool = ‘cheap-source-map’; // works but not original ts and misses line numbers
• devtool = ‘cheap-eval-source-map’; // fails
• devtool = ‘eval’; // works but not original ts

Thanks @ruscoder, using SourceMapDevToolPlugin made my day

  // devtool: 'cheap-module-eval-source-map',
  plugins: [
    new webpack.SourceMapDevToolPlugin(),
    ...
  ],

This is very much still an issue.

+1

After upgrading to webpack 3 I also experienced problems. This combination works for me now:

Chrome: 60.0.3112.78 webpack: 3.4.1 with cheap-module-source-map

fyi. “breakpoints not triggering in eval-xxx-source-map” is a browser bug. It’s reported here:

https://bugs.chromium.org/p/chromium/issues/detail?id=459499#c22

https://twitter.com/wSokra/status/869490447298723840

I found it interesting that there are so many people subscribed to this issue, but it is behind “nice to have” features like “New Analyze Tool” or “Upgrade Code Style” on the voting website. Yes, you can vote for what features Webpack team spends its time on. If you care about this, let the team know. 😉

https://webpack.js.org/vote/

Has anyone found a fix for this?

simply doing devtool: 'source-map' does not work for me. I’m using uglify and babel w/ webpack

This is still broken. Any update? I don’t think it is just chrome… GetSentry can’t seem to parse non-inline source-maps for production debugging purposes

for me, #inline-source-map is also not work.I finaly use devtool: “inline-eval-cheap-source-map”,. and it’s work.

It’s the size! Once the source maps get too large chrome is choking. I setup my project to split the node_modules from my own code and the vender chunk still dies, but my chunk’s map works! 😃

Haven’t tested all of these options, but running into some of the same issues right now on Windows. ‘inline-source-map’ allows breakpoints to be hit in Chrome, but ‘eval-source-map’ doesn’t… the breakpoints are never hit. Will do further testing with other options as I get time.

Having this same issue. Could also be related to Babel 6.

There is a workaround in the second post on this thread:

https://github.com/webpack/webpack/issues/6400

Sorry is this resolved or is there some accepted workaround? I cannot get breakpoints to work AT ALL on (host is Mac OS X El Capitan v10.11.6):

• Chrome Canary Version 56.0.2895.0 canary (64-bit)
• Safari Technology Preview Release 15 (Safari 10.1, WebKit 11603.1.8)
• Firefox Developer Edition 51.0a2(2016-10-19)(64-bit)

I don’t really ever use the latter 2 but I downloaded and tried them for completeness sake.

My dev environment is located on a Vagrant box running Ubuntu-16.04, the site itself is served through apache, but I launch a separate process for webpack-dev-server with:

webpack-dashboard -- webpack-dev-server -d --inline

I then have all the necessary scripts loaded on my page using the following script tags (as an example):

<script type="text/javascript" src="http://192.168.33.10:8000/assets/index.js"></script>

So the page auto-refreshes whenever any save any changes.

Anyway I see my original code ok, and stuff I send to the console actually gets tagged on from the correct line number, however, breakpoints refuse to work AT ALL. Things i’ve tried:

• Every possible devtool (not joking), and truthfully I have no problem with long build times so if breakpoints worked I would not mind source-map at all
• SourceMapDevToolPlugin still did not work.
• Editing my .babelrc to the very barebones ES2015 preset, I found some saying this is a problem with babel.
• Turning on sourcemaps from the babel config (both true and both) broke the whole system entirely… but I was desperate.

Anyway, I’m still mostly starting out with this stuff so i’m almost sure i must be missing something, cause this would otherwise be a much more serious and common issue online otherwise.

I’m including my webpack.config.babel.js and .babelrc files just in case. Would appreciate ANY help or suggestions as this has really put a dent in my workflow.

//webpack config
import path from 'path';
import ManifestPlugin from 'webpack-manifest-plugin';
import CommonsChunkPlugin from 'webpack/lib/optimize/CommonsChunkPlugin';
import DashboardPlugin from 'webpack-dashboard/plugin';
import WriteFilePlugin from 'write-file-webpack-plugin';
import SourceMapDevToolPlugin from 'webpack/lib/SourceMapDevToolPlugin';

module.exports = {
    context: path.join(__dirname, 'Resources'),
    entry: {
        vendor: [
                    'jquery',
                    'moment',
                    'fastclick',
                    'nprogress',
                    'bootstrap-loader',
                    'jquery-flot',
                    'select2',
                    'select2/dist/css/select2.min.css',
                    'multiselect',
                    'multiselect/css/multi-select.css',
                    'icheck',
                    'bootstrap-daterangepicker',
                    'font-awesome-sass-loader',
                ],
        index: './Index',
        login: './Login',
        actionLog: './ActionLog',
    },
    output: {
        path: path.join(__dirname, 'assets'),
        filename: '[name].js',
        chunkFilename: '[name].js',
        publicPath: 'http://192.168.33.10:8000/assets/'
    },
    devtool: 'source-map',
    module: {
        loaders: [
           {
               test: /\.js$/,
               include: path.join(__dirname, 'Resources'),
               loader: 'babel-loader'
           },
           {
               test: /\.(png|woff|woff2|eot|ttf|svg|gif)$/,
               loader: 'url-loader?limit=8192'
           },
           {   test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
               loader: "file-loader"
           },
           {   test: /\.jpg$/,
               loader: ['file?name=[name].[ext]']
           },
           {
               test   : /\.css$/,
               loaders: ['style', 'css', 'resolve-url']
           },
           {
               test: /\.scss$/,
               loaders: ['style', 'css', 'resolve-url', 'sass?sourceMaps']
           },
           {
               test: require.resolve('jquery'),
               loaders: ['expose?$', 'expose?jQuery']
           },
           {
               test: require.resolve('nprogress'),
               loaders: ['expose?NProgress']
           },
           {
               test: require.resolve('moment'),
               loaders: ['expose?moment']
           },
           {
               test: require.resolve('fastclick'),
               loaders: ['expose?FastClick']
           },
           {
               test: require.resolve('skycons'),
               loaders: ['expose?Skycons']
           },
           {
               test: require.resolve('icheck'),
               loaders: ['expose?iCheck']
           },
           {   test: /bootstrap-sass\/assets\/javascripts\//,
               loader: 'imports?jQuery=jquery'
           },
       ]
    },
    devServer: {
        host: "0.0.0.0",
        port: 8000,
        stats: 'minimal',
        clientLogLevel: 'info',
        outputPath: path.join(__dirname, 'assets'),
        watchOptions: {
            aggregateTimeout: 300,
            poll: 1000
        }
    },
    plugins: [
        new ManifestPlugin(),
        new CommonsChunkPlugin({
            name: ['bootstrap'],
            minChunks: Infinity
        }),
        // new SourceMapDevToolPlugin({
        //     filename: '[file].map',
        //     exclude: ['vendor.js'],
        //     columns: false
        // }),
        new WriteFilePlugin({
            log: false
        }),
        new DashboardPlugin()
    ]
};

I’m in the process of updating a system which had mostly legacy JS code, which is the reason behind some of the includes and loaders, I also need the WriteFilePlugin as I use a PHP Templating engine Twig to insert my webpack entry points, and this requires the manifest.json file to be generated in my /assets/ directory on disk, twig has no access to the files webpack keeps on memory.

// .babelrc
{
  "presets": [
    "react",
    "es2015",
    "stage-0"
  ],
  "plugins": [
    "transform-runtime",
    "react-html-attrs",
    "transform-decorators-legacy",
    "transform-class-properties"
  ],
  "retainLines": true 
}

Was just experimenting with the retainLines option, only difference I saw from this is that the I could set breakpoints on the lines I wanted in the devtool (sometimes lines with valid code would be greyed out). That being said, these would still be completely ignored.

I try to put a breakpoint on that console.log… but it gets completely ignored.

Anyway, I apologise for the ridiculously long post, I just wanted to be as thorough as possible to make sure I don’t miss some key detail without knowing.

P.S. placing a debugger command in the file does what it’s meant to, but stepping forward from there goes back to the webpack generated files, so impossible to actually follow what’s going on from there.

Had the same issue , fixed by changing source-map to inline-source-map as suggested by @xuefengwang

Note that the chromium bug can be starred for visibility - I’ve done so and encourage others to do so as well 😃

Upgraded to Webpack 1.14.0, cheap-module-source-map works, but cheap-module-eval-source-map doesn’t.

@faceyspacey, the fix in webpack 1.14.0 is that it enforces source-map-list@0.1.7 (which contains the fix). If you remove your node_modules/ folder (and upgrade your yarn.lock / npm-shrinkwrap.json) and re-install your modules, you should also get source-map-list@0.1.7.

source-map is working for me (breakpoints work, correct code shown) on Windows 7 Enterprise, webpack 1.12.

However, the performance hit on incremental builds is terrifying (up to 4 seconds from 0.5), so it does not really help.

UPDATE: eval-source-map seems to be a decent compromise. Build times are ok (up to around 1s from 0.5), original code shown, and breakpoints mostly work. There are some very strange corner cases where the debugger simply does not kick in.

+1 OSX

Just throwing some tips for people on Chrome with issues.

If you have the original files, you don’t want to use to include the source code in your source map. Use nosources-source-map so that the source map only includes weak references to files and lines. Then Chrome will map that to your workspace files. If you include sources, then you’re essentially telling Chrome to look in webpack://* for the sources instead.

It would be nice if you could remap webpack:// to your project folder, but Chrome removed this functionality. If you are using Visual Studio Code with the popular Chrome debugging plug-in, be sure to create a workspace remapping.

People still having issues – have you ensured you have Enable JavaScript source maps checked in your settings? For some reason unclear to me, this setting became unchecked recently. It’s a once-and-done sort of thing, so I forgot about it’s existence.

@screendriver

Which versions were you using. Now that I’m @ Microsoft on the EdgeDevTools team I’d like to work with Paul Irish and the rest of the Chrome Dev Tools folks and make sure we stay in sync if possible.

Funny, cheap-module-source-map works in FF, but doesn’t work in Chrome cheap-module-inline-source-map doesn’t work in FF, but does work in Chrome 😭

devtool: '#source-maps' not working for me. Other attempts failed as well

@andrei-cacio : here we go.

162121_webpack_config.zip

devtool: '#inline-source-map' is working for me at least in Chrome Canary on Mac.

Btw, since I’m stuck using ‘cheap-module-source-map’, I decided to do some profiling of webpack to see if there’s anything that could be cached/changed to speed up the sourcemap generation on incremental builds. Here’s one improvement I found:

var MappingsContext = require("source-list-map").MappingsContext;

/**
 * Note: this code was copied over from the original implementation and
 * modified to do lookups using a Map to get O(log(n)) performance instead of indexOf(), which is O(n)
 */
MappingsContext.prototype.ensureSource = function(source, originalSource) {
    this._sourcesIdxMap = this._sourcesIdxMap || new Map();
    var idx = this._sourcesIdxMap.get(source);
    if(idx !== undefined) {
        return idx;
    }

    // old code follows:
    // originally lookup was done using indexOf
    // var idx = this.sources.indexOf(source);

    idx = this.sources.length;
    this.sources.push(source);
    this._sourcesIdxMap.set(source, idx);
    this.sourcesContent.push(originalSource);
    if(typeof originalSource === "string")
        this.hasSourceContent = true;
    return idx;
};

The other time hog is the fromStringWithSourceMap() function, but I’m not exactly sure how to refactor it. The problem seems to be related to:

1. base64VLQ.decode() - happening a lot, not sure why decoding is necessary to generate the sourcemaps
2. The lines of code being split into an array and then being put back together? I’ve pasted the source code here in case somebody gets an idea:

var base64VLQ = require("./base64-vlq");
var SourceNode = require("./SourceNode");
var CodeNode = require("./CodeNode");
var SourceListMap = require("./SourceListMap");

module.exports = function fromStringWithSourceMap(code, map) {
    var sources = map.sources;
    var sourcesContent = map.sourcesContent;
    var mappings = map.mappings.split(";");
    var lines = code.split("\n");
    var nodes = [];
    var currentNode = null;
    var currentLine = 1;
    var currentSourceIdx = 0;
    var currentSourceNodeLine;
    mappings.forEach(function(mapping, idx) {
        var line = lines[idx];
        if(typeof line === 'undefined') return;
        if(idx !== lines.length - 1) line += "\n";
        if(!mapping)
            return addCode(line);
        mapping = { value: 0, rest: mapping };
        var lineAdded = false;
        while(mapping.rest)
            lineAdded = processMapping(mapping, line, lineAdded) || lineAdded;
        if(!lineAdded)
            addCode(line);
    });
    if(mappings.length < lines.length) {
        var idx = mappings.length;
        while(!lines[idx].trim() && idx < lines.length-1) {
            addCode(lines[idx] + "\n");
            idx++;
        }
        addCode(lines.slice(idx).join("\n"));
    }
    return new SourceListMap(nodes);
    function processMapping(mapping, line, ignore) {
        if(mapping.rest && mapping.rest[0] !== ",") {
            base64VLQ.decode(mapping.rest, mapping);
        }
        if(!mapping.rest)
            return false;
        if(mapping.rest[0] === ",") {
            mapping.rest = mapping.rest.substr(1);
            return false;
        }

        base64VLQ.decode(mapping.rest, mapping);
        var sourceIdx = mapping.value + currentSourceIdx;
        currentSourceIdx = sourceIdx;

        if(mapping.rest && mapping.rest[0] !== ",") {
            base64VLQ.decode(mapping.rest, mapping);
            var linePosition = mapping.value + currentLine;
            currentLine = linePosition;
        } else {
            var linePosition = currentLine;
        }

        if(mapping.rest && mapping.rest[0] === ",") {
            mapping.rest = mapping.rest.substr(1);
        }

        if(!ignore) {
            addSource(line, sources ? sources[sourceIdx] : null, sourcesContent ? sourcesContent[sourceIdx] : null, linePosition)
            return true;
        }
    }
    function addCode(generatedCode) {
        if(currentNode && currentNode instanceof CodeNode) {
            currentNode.addGeneratedCode(generatedCode);
        } else if(currentNode && currentNode instanceof SourceNode && !generatedCode.trim()) {
            currentNode.generatedCode += generatedCode;
            currentSourceNodeLine++;
        } else {
            currentNode = new CodeNode(generatedCode);
            nodes.push(currentNode);
        }
    }
    function addSource(generatedCode, source, originalSource, linePosition) {
        if(currentNode && currentNode instanceof SourceNode &&
            currentNode.source === source &&
            currentSourceNodeLine === linePosition
        ) {
            currentNode.generatedCode += generatedCode;
            currentSourceNodeLine++;
        } else {
            currentNode = new SourceNode(generatedCode, source, originalSource, linePosition);
            currentSourceNodeLine = linePosition + 1;
            nodes.push(currentNode);
        }
    }
};

Just faced with the same one, fixed by set devtoolModuleFilenameTemplate: ‘[absolute-resource-path]’ to the output section in config. osx

I’m having this issue too. The interesting thing is that it only happens in Windows. In OS X and Linux the source maps line up correctly. Maybe there is some kind of LF/CRLF issue?

I verified that my source maps generated in windows, linux, and OS X line up correctly using this tool: http://sokra.github.io/source-map-visualization/

inline source maps works

Anyone got this to play nicely with vscode chrome debbuger At this rate, i’ll be bald by the end of the day

Hooray! With the latest Chrome 60 it works again! 🎉 💃 😎

As a workaround download latest chromium build for development https://www.chromium.org/getting-involved/download-chromium

still an issue for me in terms of hitting breakpoints in chrome dev tools on page load specifically. i’ve tried cheap-module-source-map, source-map, inline-source-map, eval, and cheap-module-eval-source-map

(chrome: Version 55.0.2883.87)

Hi everyone kind enough to report in this thread, if you didn’t know we have shipped webpack 2.2.1 to the latest tag on npm. I’d love if you could all test and report the following:

Does sourcemaps work correctly? If not, report the symptom: Sourcemap type: (IE: devtool: “cheap-module-source-map”) Chrome version: OS:

I have a new working group with some Chrome Developers looking to tackle and address this issue. So looking forward to get as much data as possible to verify this is still an issue or not. Thank you all so much.

Using webpack 2.2.0 final release works great for me with devtool: '#source-maps',

Chrome (v 55.0.2883.87 m) on windows., webpack 2.2.0-rc.3

devtool: "cheap-module-source-map" used to work just fine but doesn’t anymore using to

plugins[
 ....
new webpack.SourceMapDevToolPlugin()
...
])

Worked perfectly

So I put together the most simplistic example I could come up with.

https://github.com/fracmak/sourcemap-fail

It’s basically React/ReactDOM with react-css-modules. If you comment out the react-css-modules in src/Test/index.js on line 2, you can now place a breakpoint on the console.log(). If you put in that import, the breakpoint is no longer accurate.

This is running against Chrome 55.0.2883.75 OSX, running node 6.9.1

Just a note for others following along that the relevant package is named source-list-map, not source-map-list.

I can second @brianblakely and @matteoantoci’s problems with cheap-module-eval-source-map. I also tried @ruscoder’s solution, which did work, but killed performance. I set columns to false, to see if performance would improve, but I got the same problem as before, with the undefined in the map.

The issue reported with “eval” sourcemaps is https://bugs.chromium.org/p/chromium/issues/detail?id=459499, which is still open.

The issue reported with non-inline sourcemaps is https://bugs.chromium.org/p/chromium/issues/detail?id=611328, which is resolved.

+1 Windows

EDIT: Fixed in canary. Definitely a chrome issue.

Configuring with this devtool: 'inline-module-source-map' into webpack fixed my issues where debugger wasn’t acessing the current context. I’m running with webpack-dev-server and webpack 4

this solution worked for me. Thanks @wallynm

@csvan I know how you feel, I still think Chrome devtools is the best available.

My bug report was recently updated to WontFix saying “This is a known issue with webpack; we can’t do much” because “Webpack changes the content of the sourcemaps resources”

It would seem that Chrome has indicated that the fault is solely with Webpack, but I feel that a solution would not be that difficult (esp. if a dev was fluent in WDS & chrome devtools internals). //cc @aslushnikov @pavelfeldman

I’m still seeing issues with the following setup: webpack: 3.4.1 (devtool set to inline-source-map) Node: v6.9.5 Chrome:60.3.3112.78

I suppose I should try Node v8.1.0 although in theory should the node version matter?

Now that I’m @ Microsoft on the EdgeDevTools team

I read that on Twitter. Congratulations! 🎉 😉

Currently I have following versions:

webpack: 3.4.1 (devtool set to inline-source-map) TypeScript: 2.4.2 ts-loader: 2.3.2 Node: v8.1.0 Chrome: 60.0.3112.78

Looks like eval sourcemaps might have been fixed in webpack fairly recently 😃 https://github.com/webpack/webpack/blob/master/lib/EvalSourceMapDevToolModuleTemplatePlugin.js#L65 (based on workaround here I suppose: https://bugs.chromium.org/p/chromium/issues/detail?id=459499#c23)

I just copy pasted that line into my local node_modules/../EvalSourceMapDevToolModuleTemplatePlugin.js and it worked!!! (I am on an older version of webpack)

@jgerigmeyer Oh, missed one - table updated. Spoilers: It works the same as cheap-module-source-map 🎉.

I’d be curious how cheap-module-inline-source-map compares to those in the table?

The #source-map works well for me, please mark sure you webpack-dev-server command dont’t include -d param, or devtool config won’t take effect.

package.json

{
    "scripts": {
        "dev": "webpack-dev-server -d --inline --hot --env.dev"
    }
}

Once I remove -d param, it worked well.

{
    "scripts": {
        "dev": "webpack-dev-server --inline --hot --env.dev"
    }
}

EDIT: Upgrading from webpack 2.2.1 to 2.3.1 fixed the issue above for me!

Looks like there was a bugfix in 2.3.0 “Fix cheap-source-maps when combined with ES Modules (lines were offset)” which is probably related.

Thanks for the work on this @TheLarkInn !

I’m seeing issues as well - tried every config combo I can think of to generate full production source maps, but when I trigger errors they always point to the wrong location in the original source.

module.exports = {
  // ...
  devtool: 'source-map,
  plugins: [
    new UglifyJSPlugin({ sourceMap: true }),
  ],
  // ...
};

I’ve tried different things like…

• using SourceMapDevToolPlugin instead of devtool,
• using Babili instead of uglify,
• and limiting my multiple app entry points to just 1

When I generate an error, the original source shows up fine in the Chrome inspector, but the error points to the completely wrong location in my src.

I also tried to validate the source maps with sourcemaps.io it results in hundreds of errors that look like this:

Any ideas? Spent hours on hours looking for a solution

Versions: webpack: 2.2.1 babel-loader: 6.4.0 uglifyjs-webpack-plugin: 0.3.0 uglify-js: 2.8.7

Prefixing @, # or #@ will enforce a pragma style. (Defaults to @ in webpack@1 and # in webpack@2; using # is recommended)

@csvan http://webpack.github.io/docs/configuration.html#devtool

since webpack 2, the UglifyJsPlugin apparently has sourceMap: false by default so you need to explicitly set it to true in the config

https://gist.github.com/sokra/27b24881210b56bbaff7#gistcomment-1863573

i think people are looking for the cheap source maps to work

Sorry, I should’ve been clear I’m referring particularly to Webpack 1.x. I don’t know where/when the corresponding fix for Webpack 2 would land.

@csvan Your solution worked for me, breakpoints work 100% as long as I do not hot reload, once I hot reload, they work 0%. Is this your case too?

and fixed in Version 52.0.2743.82 beta (64-bit) for me…

@elado Looks like something landed recently but you need to be using Chrome Canary, see here (scroll to bottom): https://bugs.chromium.org/p/chromium/issues/detail?id=327092

Actual commit here: https://codereview.chromium.org/1770263002/diff/20001/third_party/WebKit/Source/devtools/front_end/sources/SourceMapNamesResolver.js

There certainly seems to be a problem with Chrome 51. See Chrome Bug 611328.