Repository navigation
web pack source map not working for some devtool options. #5491
Description
Activity
I am having the same problem right now. Eval source maps work fine.
Webpack: ^2.2.0
Chrome: 60.0.3112.101 (Official Build) (64-bit)
OSX: 10.12.6Also experiencing this issue:
Webpack: 3.3.0
Chrome: Version 60.0.3112.101 (Official Build) (64-bit)I've explored this further and my sourcemaps are working as expected in Firefox. Just not in Chrome.
Reacted by Pamelais that a similar issue to this? #5569 (comment)
@MACSkeptic . Not really. I did not even specify UglifyJsPlugin in my config. Sourcemap is just not working properly when multiple entries are set to webpack. @petermikitsh , I still have the issue in Chrome, Firefox and Safari. That's interesting. Could you provide a sample repo? Maybe, I can test it as well and I can see that is it the same issue that I have?
#5569 provide a very simple sample repo. You can see it in it.
I'm the issuer. It seems that thewebpackowner has no time to deal with the bug or he thinks it's NOT a bug. He may think we just use it in a wrong way , however it's obviouse that the bug is not reasonable. Now I feel frustrated.And I updated the chrome to the newest version (60.0.3112.113). It still worked fine.
And the configuration isdevtool: 'source-map',Hey @yincu . It is already marked as an important bug. You cannot expect them to fix the bug right away as there are tons of bugs are on their list.
As I described in my first message, watch console.logs carefully. Otherwise, sourcemaps files are already created.
I just cloned my repo and did run it again. It is still a clear bug as you may see in the screenshot. Expecting behavior is that show the exact file and line. Not the bundled file. How about your console?
Reacted by BakshiI get what you said. I reproduced the bug. However, it seems it may be a browser bug of chrome or it's NOT a bug.
When you browser http://localhost:3000/ page without a devtool window displayed. You'll get the right source map. Or if you get what you got in your above post picture. You can close the devtool window of chrome and open it again. Boom! You get what you want.The source map files will not be get from the server unless you reopen the devtool window. These files are not expected to be acccesed by users when browsering the pages. They will not be downloaded along with the js or css files.
These files will only be downloaded and parsed when the devtool window is reopened.It might be a browser bug, but it happens in other 3 browsers as well. Plus, it works fine with some other sourcemap types. Besides, it works as well if I assign only one entry to be bundled. I am not an expert and I cannot speak in a certain way, but it seems this bug is more related to webpack.
You could test this way with other sourcemap types to see if it works the same.
The test with the configurationdevtool: 'source-map'suggests that it has nothing to do with webpack.Source maps are used for debugging. The behavior of Chrome is reasonable .
Reacted by Søren Nguyen Boisen, Rémi Chanaud, Max, AceGentile and Bryan HoangGot the same issue,
evalconfig works.3 remaining items
- added a commit that references this issue
on Dec 13, 2017 Facing the same problem, it is uglifying when not told to and not having the devtool source map in cheap-source-map, source-map or any devtool option like inline-source-map.
Update: Just fixed it using mode in webpack 4
@devssh so you get sourcemaps even with
devtool: "source-map", or what?
Can you post your webpack config?Reacted by AakashYes here is my baseConfig
const path = require('path'); const webpack = require('webpack'); module.exports = { devtool: 'cheap-module-source-map', entry: ['./client/src/index.js'], output: { path: path.join(__dirname, '../server/public'), filename: 'static/bundle.js', publicPath: '/' }, plugins: [ new webpack.DefinePlugin({ 'HOST_MACHINE_URL': JSON.stringify(process.env.HOST_URL) }), new webpack.NoEmitOnErrorsPlugin() ], module: { rules: [ { test: /.html$/, loaders: "html-loader" }, { test: /\.(js)$/, exclude: /node_modules/, use: ['babel-loader'] }, { test: /\.(scss|css)$/, use: ["style-loader", "css-loader", "sass-loader"] }, { test: /\.(eot|ttf|woff2|woff|jpg|png|svg)(\?[a-z0-9]+)?$/, use: [{ loader:'file-loader', options: { name: '[name].[ext]', outputPath: 'static/', // where the fonts will go publicPath: '/' // override the default path } }] } ], } };Now in the dev server
const baseConfig = require('./webpack.base.conf'); const webpack = require('webpack'); console.log(baseConfig.entry.push.apply(baseConfig.entry, [ 'webpack-hot-middleware/client?reload=true', 'react-hot-loader/patch' ])); baseConfig.entry.reverse(); baseConfig.plugins.push.apply(baseConfig.plugins, [ new webpack.NamedModulesPlugin(), new webpack.HotModuleReplacementPlugin(), ]); baseConfig.devServer = { hot: true }; module.exports = baseConfig;What was added to fix the issue was
baseConfig.mode = 'development';and it happened because we migrated from Webpack 3 to Webpack 4
- Reacted by JanakiSathiyamurthy7, Tilwin Joy, John Hornsby, Baha_Kaiybekov, hphat204, Oleksandr Shmundiak and João Scaravonatti
Same thing here, can't get any sourcemaps other than
*-eval-*sourcemaps to work 😡Reacted by Marvin Heilemann, matthiasp42, Illia Lukianov, Christian Kaisermann, Natasha Koh, Michael A. Leonetti and Eli AlbertIf the script is within an iframe, you have to enable "Search in anonymous and content scripts" in Chrome.
Reacted by Noah Potter and Adam DoyleUsing webpack 4 with source-map option. It work in 20% of cases, even don't know how to reproduce it. Previously I use gulp, and gulp put source maps inside of js bundle. Webpack put source maps as separated file, think it is a root problem. Will try something like 'cheap-eval-source-map', hope it will help (latest version of chrome).
I had the same problem in chrome, but it worked in firefox
Fixed in webpack@4, Firefox has some problems with source maps, here more information #1194 (fixed in nightly)
I want to close this issue, because it is fixed, but if you faced with the problem again, feel free to open a new issue with reproducible test repo, we have many tests on source maps
Running on
webpack==4.41.2, the fix for me was settingsourceMap: truefor the TerserPlugin, as the docs highlight:sourceMap: true, // Must be set to true if using source-maps in productionThis change meant I started to get source maps for all the available
devtoolvalues, not just theeval*ones.Webpack 5 loses support for
sourceMap: true
Terser Plugin 5.0.0 release Notes
What is the equivalent option for webpack5?Webpack 5 loses support for
sourceMap: trueTerser Plugin 5.0.0 release Notes What is the equivalent option for webpack5?Webpack 5 devtools hidden-source-map not generate sourcemap
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority



Do you want to request a feature or report a bug?
bug
What is the current behavior?
Sourcemap is not working for some devtool options. Tested options:
eval: working
cheap-eval-source-map: working
cheap-source-map: not working
cheap-module-eval-source-map: working
cheap-module-source-map: not working
source-map: not working
inline-source-map: not working
hidden-source-map: not working
nosources-source-map: not working
If the current behavior is a bug, please provide the steps to reproduce.
I reproduced the bug in this repo: https://github.com/SemihGk/waka-player
npm install -> npm run prod -> watch console messages in localhost:3000It's really a weird issue. I am not sure any plugin causes this error. I do not think so. Just in case, you may check that in the repo. It is very basic sample repo and just used a couple webpack plugins such as html-webpack-plugin and copy-webpack-plugin. You can find those plugins' versions in package.json file. I suspect the compatibility between webpack and babel-loader.
What is the expected behavior?
source map should work in all devtool options.
If this is a feature request, what is motivation or use case for changing the behavior?
It's bug.
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
"webpack": "^3.5.1",
Mac OS: 10.12.6
node: 8.2.1
Tested on Chrome 60, Mozilla 54, Safari 10.1