laravel-mix: mix.sourceMaps() does not work

Yes, can also confirm that this appears to be buggy. How are devs working effectively without this? The code mentioned above seems to be a temporary workaround:

.sourceMaps(true, 'source-map')

Note that this appears to output both JS and CSS sourcemaps in development mode, but only JS sourcemaps in production mode. I haven’t confirmed yet if the sourcemaps are actually accurate.

Thanks, this workaround worked for me:

if ( ! mix.inProduction()) {
    mix.webpackConfig({
        devtool: 'inline-source-map'
    })
}

I’m going to leave this issue open though as I believe the original option isn’t working.

Another workaround: .sourceMaps(true, 'source-map'). That first parameter is a boolean value for if you would source maps when ran as production as well.

The second parameter is the type of of source map. The interesting thing is that if you use the default value of eval-source-map everything seems to work fine. I’m not sure why it would work fine when you pass it in but not when you let it default to the value.

https://github.com/JeffreyWay/laravel-mix/blob/52582c120f2eaef0146d63a43c41235f40e3f030/src/Api.js#L12

I, too, have them both (on Mix 2.1.14) and it’s working well:

...
.sourceMaps()
.webpackConfig({devtool: 'source-map'})
...

Another workaround: .sourceMaps(true, 'source-map'). That first parameter is a boolean value for if you would source maps when ran as production as well.

The second parameter is the type of of source map. The interesting thing is that if you use the default value of eval-source-map everything seems to work fine. I’m not sure why it would work fine when you pass it in but not when you let it default to the value.

https://github.com/JeffreyWay/laravel-mix/blob/52582c120f2eaef0146d63a43c41235f40e3f030/src/Api.js#L12

I found that .sourceMaps(false, 'source-map') forced source maps in development mode.

I ran into a similar problem earlier. #879 fix worked for me when I added the following to my options:

mix.options({
    processCssUrls: false,
})
   .sourceMaps()
   .js(...)
   .sass(...);

For me there was an upstream issue with the resolve-url-loader dependency, but it recently got a re-write to postCSS and should resolve the issue. I don’t have the time right now to work on a PR for this right now, however.

https://github.com/bholloway/resolve-url-loader/releases/tag/v3.0.0

Pull request #2282 resolves the prod source map issue for sass files.

Details:

Sass sourcemaps fail to generate in production builds due to cssnano combined with OptimizeCSSAssetsPlugin. Moving cssnano into postcss-loader resolves issue. More detail https://www.webfoobar.com/node/109

Note eval-source-maps still will not work at all for CSS, so implementers must use Mix.sourceMaps(true, 'source-map') to allow development builds to successfully generate sourcemaps. Production builds default to the source-map type.

The sourcemaps might generate, but they point to totally wrong files.

For example: I have a main style.sass file that imports a partial _base.sass.

@import 'base'

In _base.sass I have a simple sass rule:

body
   background: green

When I open the inspector in ChromeDevTools the rule is attributed to style.sass instead of _base.sass.

This is a fundamental thing that works flawlessly in gulp.

I have also a lot of problems with sourceMaps, but by doing this:

mix.webpackConfig({ devtool: 'source-map' })

It seems to be working now.

Thanks to the information here:

https://stackoverflow.com/a/37653167 https://webpack.js.org/configuration/devtool/

@75th Have you tried putting both?

mix.webpackConfig({
        devtool: 'inline-source-map'
    })

AND mix.sourceMaps()

I used to only have the webpackConfig() method and it was working fine. I haven’t been debugging in Chrome lately (2+ weeks) but when I did today, I noticed that source maps weren’t working anymore. Adding in mix.sourceMaps() worked.

It’s a quick, and dirty fix but I just needed to get the source maps up and running.

I was experiencing same with mix 4.0. I rearranged my webpack.mix.js so that mix.sourceMaps() is called before anything else. Problem resolved; no workarounds needed.

This worked for me, but only when combined with…

I have also a lot of problems with sourceMaps, but by doing this:

mix.webpackConfig({ devtool: ‘source-map’ })

It seems to be working now.

Thank you @arxeiss and @filipve1994 .

I’m on node v8.11.2, npm 6.1.0, Laravel Mix 4.1.2, using outside of Laravel by way of the instructions in the docs, and using mix.less().

Omg, has this seriously been open since 18th of October? Isn’t this kinda like an official package with laravel? Thx @MDooley47 at least that moves me forward for now.

I, too, have them both (on Mix 2.1.14) and it’s working well:

...
.sourceMaps()
.webpackConfig({devtool: 'source-map'})
...

It Worked for me aswell! tnks!

@bentaber Thank you! I was wrestling with this problem for hours, and after manually patching Mix with the code from your PR, it’s working perfectly. Let’s hope it’s merged in soon.

tried all workarounds posted here, the only thing that worked is to inline the map, if not, the map will generate but won’t work, all the rules point to style.css as @bonovski mentioned above.

here’s my webpack.mix.js

mix
.sourceMaps()
.options({
	processCssUrls: false
})
.webpackConfig({devtool: 'inline-source-map'})
.sass('./style.scss', './assets/styles/style.min.css', {implementation: require('node-sass')})
.tailwind('./tailwind.config.js')

Can confirm here. mix version: 4.0.15 Node Version (node -v): 10.13.0 NPM Version (npm -v): 6.4.1 OS: Windows

With default webpack.mix.js file just added mix.sourceMaps(); and no CSS maps is created

Update: I found, that during npm run dev Sass maps are created, but saved inside final scripts.js file. Not within separate .map file

I was experiencing same with mix 4.0. I rearranged my webpack.mix.js so that mix.sourceMaps() is called before anything else. Problem resolved; no workarounds needed.

Well, I got the sass sourcemap to generate, the problem is now that the references point to the wrong files when viewed in the browser inspector.