original.line and original.column are not numbers -- you probably meant to omit the original mapping entirely and only map the generated position. If so, pass null for the original mapping instead of an object with empty or null values.
It seems to just have started happening ~8-12 hours ago.
Neither webpack, webpack-sources, nor source-map have had new releases.
Perhaps related to this https://github.com/webpack-contrib/babel-minify-webpack-plugin/issues/68
I can confirm this as well. I just saw this issue about 10 minutes ago and came here to check if anyone else was too. I just upgraded to 2.11.1 before that build. Perhaps there is something related there?
actually i just reverted back to 2.8.5 and am still having the same error, so probably not that.
Started happening today in vue-cli also it looks like: https://github.com/vuejs/vue-cli/issues/4210
I imagine its a dependency issue somewhere down the tree.
Might be worth cross referencing pack-lock.json files of gatsby-cli and vue-cli, match commonalities in packages and versions, then find most recently updated on the list and triage from there?
Seems a bug in terser 4.0.1
I thought I was losing my mind.
Happened to me while presenting 馃槀
Here's a workaround, if you use yarn. You can force a working version of terser by adding the following lines to your package.json:
"resolutions": {
"terser-webpack-plugin/terser": "4.0.0"
}
@szimek Didn't change anything for me
@KyleAMathews @szimek seems it this has been resolved? See this sandbox link, build runs with no errors.
@joeynimu This sandbox uses terser 4.0.0. You can check it using yarn why terser. If you run yarn upgrade there, then you'll get terser 4.0.1 and yarn build will start failing.
@iRoachie I tried it with a new project and it fixed this issue for me. It's possible that you have other library that has terser as a dependency. You can run yarn why terser to confirm how many versions of terser you have and which one is actually used.
You can try this to force terser 4.0.0 for all libraries (if I understand correctly how resolutions work in yarn):
"resolutions": {
"terser": "4.0.0"
}
Hey @joeynimu that codesandbox is using [email protected], is the gatsby version not the issue here but terser?
@szimek I have [email protected] are you suggesting with the resolutions in my package.json that I should use [email protected]?
It's not really clear on where this should go either:
You can try this to force terser 4.0.0 for all libraries (if I understand correctly how resolutions work in yarn):
"resolutions": { "terser": "4.0.0" }
@spences10 As @sodatea mentioned before, this issue is caused by terser 4.0.1 library (https://github.com/terser-js/terser/issues/380). terser 4.0.0 doesn't have this issue.
The resolutions option should be added to your package.json file. You can read more about it here: https://yarnpkg.com/lang/en/docs/selective-version-resolutions/. Adding "terser-webpack-plugin/terser": "4.0.0" to resolutions worked for me on a new Gatsby project with the default starter, but it might not work when there are other libraries that have terser as their dependency, so one can also try adding "terser": "4.0.0" there instead.
When a new Gatsby project is generated, it uses terser 4.0.0. However, when you upgrade all packages (or maybe even only gatsby), you'll end up with the latest terser 4.0.1 and then you'll start getting this error on yarn build, when terser tries to minify your JS code.
And once again - one can check which version(s) of terser are used in a project by running yarn why terser.
@szimek thanks, I was just looking at the terser error when I saw you referenced this issue there :grin:
Ok, so I added the additional resolutions property to my package.json and was still getting build errors, so I defaulted to:
yarn gatsby clean
rm -rf node_modules/
yarn
yarn build
And it's built ok this time, I'm going to push it up to netlify and see if it still doesn't break.
Thanks
@joeynimu This sandbox uses terser 4.0.0. You can check it using
yarn why terser. If you runyarn upgradethere, then you'll get terser 4.0.1 andyarn buildwill start failing.@iRoachie I tried it with a new project and it fixed this issue for me. It's possible that you have other library that has
terseras a dependency. You can runyarn why terserto confirm how many versions of terser you have and which one is actually used.You can try this to force terser 4.0.0 for all libraries (if I understand correctly how resolutions work in yarn):
"resolutions": { "terser": "4.0.0" }
I see. I did a yarn upgrade on the sandbox which now caused the build to fail. After adding a resolution to the package.json like @szimek has suggested, the build ran okay. Link to sandbox
Note The sandbox is the default gatsby starter template with the default installs/dependancies.
Temporary fix published in [email protected], thanks @pieh!
Somehow I can only get v2.10.0 working with the resolution pinning terser to v4.0.0.
And v2.13.1 works neither with the resolution nor without.
So I will have to wait for a working version.
I also had this issue. At first I just did a webpack workaround in gatsby-node.js, but when I added the gatsby-plugin-netlify-cms, my build broke. And I am using npm, and had no intention of switching to yarn just because of the source maps issue. So I ended up doing the npm version of resolutions.
npm-force-resolutions Github repo
I have tested it on gatsby 2.10.0 and it worked. I had a successful build. However, since 2.10.0 seemed to be the last version which did not have peer dep issues, I am sticking with it until there is a stable fix. I don't consider this a stable fix. I also don't know if the build will work on Netlify. So far it is working locally.
Note: I actually tried the latest version of terser (at least last night), so am using 4.1.2. And it worked on my build. At least locally. We'll see about what happens when I push to Netlify.
Most helpful comment
Seems a bug in terser 4.0.1