[vite:css] [postcss] original.line and original.column are not numbers about postcss

[ai]

This is how small is the fix https://github.com/7rulnik/source-map-js/pull/20/files

I am really disappointment in JS community. You are waiting for free support for your commercial projects from open source maintainers and do not want to spend a little of your time to help us in return.

Instead, you are suggesting bad and dangerous hacks (disabling source map will decrease DX) to hide the error instead of debugging it.

[romainmenke]

I've traced this further down into mini-css-extract-plugin and webpack-sources.

https://github.com/webpack-contrib/mini-css-extract-plugin/blob/8480bce915fbb9482823397bff296817db7924d6/src/index.js#L1459

source.add("\n");

https://github.com/webpack/webpack-sources/blob/19d4e8eee5e980ccaf2d8a08f2bbf786ae0fbc8c/lib/ConcatSource.js#L36-L45

	add(item) {
		if (item instanceof ConcatSource) {
			for (const child of item._children) {
				this._children.push(child);
			}
		} else {
			this._children.push(item);
		}
		this._isOptimized = false;
	}

---

To summarize :

• some use webpack to process CSS. swagger-ui for example uses webpack
• css-loader exposes processed CSS as a JS module.
• mini-css-extract-plugin extracts the CSS from the JS module
• mini-css-extract-plugin has side effects
  • adding layer, media, ... wrapping statements
  • adding a newline
  • ...
• webpack-sources has a ConcatSource class with an add method
  • this add method also accepts string values
  • string values are not sufficient when building complete sourcemaps
• original.line and original.column are missing

So this issue only happens because mini-css-extract-plugin inserts arbitrary bits of strings and these bits can not be traced back to the original source because it just uses string values.

---

I've also filed an issue with mini-css-extract-plugin : webpack-contrib/mini-css-extract-plugin#1075

[ai]

source-map-js hasn't had a release in over 2 years

I spoke with maintainer. He is active, just need a help with the research.

[silverwind]

Has anyone solved this issue in case of Vite?

In your package.json, with npm:

  "overrides": {
    "postcss": "8.4.32"
  }

For a better workaround, vite needs to allow user to pass in {map: false} to postcss, but this is currently not possible because of vite's hardcoding of postcss.process options.

[ai]

Please send PR to source-map-js.

If I will hide this issue, nobody will fix it never.

[strmer15]

I've been having this same issue, but with a SASS file (ending in .scss). I debugged through it, apparently it's this change that was made to check for falsey options instead of just undefined - c37346d.

Because of that, the Vite call to the postcss process function falls into the NoWorkResult branch, in the case where it sets the parser option to be null instead of undefined, see https://github.com/vitejs/vite/blob/06494443194763d6dd125740961cec82dd9a29d6/packages/vite/src/node/plugins/css.ts#L1303 (actually check the post I made after this, it's coming from postcss-import).

Once I revert back to the old checks, everything works again for me.

[strmer15]

@ai I've got the code uploaded to StackBlitz at https://stackblitz.com/edit/vitejs-vite-qgtskm

The culprit in my project appears to be a CSS file that has its own map built in by a component library that we share across projects. I've updated all the dependencies that we have for the component library project, except for postcss-preset-env (we're still using v7 because we relied on importFrom and didn't have time to figure out how to migrate from it yet). After that I rebuilt it again and tried with the newly built css and map file just to be sure, but it still fails.

The postcss plugins that we're using for this component library are postcss-import, postcss-url, @csstools/postcss-relative-color-syntax, and postcss-preset-env. The CSS and map are built with webpack, postcss-loader, css-loader, and mini-css-extract-plugin.

[silverwind]

Here is another reproduction: https://stackblitz.com/edit/vitejs-vite-wdrh5m?file=src%2FApp.css

Steps I've took:

1. Initialize a fresh vite-react project
2. npm install swagger-ui-dist
3. Add @import 'swagger-ui-dist/swagger-ui.css'; to App.css

The imported file is shipped with this source map. Downgrading postcss to 8.4.32 does resolve the issue.

[romainmenke]

I filed an issue upstream : 7rulnik/source-map-js#18

[ai]

PostCSS 8.4.36 was released.

It should fix the bug by ignoring broken mappings from previous source map.

[kaiyoma]

I must be missing something here, because when I upgrade from 8.4.31 to 8.4.36, I see the same exact problem that I posted originally:

10:10:57  [vite:css] [postcss] 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.
10:10:57  file: /home/jenkins/workspace/Geiger/geiger-review/src/styles.less:undefined:undefined
10:10:57  /home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/source-map-js/lib/source-map-generator.js:289
10:10:57          throw new Error(message);
10:10:57                ^
10:10:57  
10:10:57  Error: [postcss] 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.
10:10:57      at SourceMapGenerator.SourceMapGenerator_validateMapping [as _validateMapping] (/home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/source-map-js/lib/source-map-generator.js:289:15)
10:10:57      at SourceMapGenerator.SourceMapGenerator_addMapping [as addMapping] (/home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/source-map-js/lib/source-map-generator.js:111:16)
10:10:57      at /home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/source-map-js/lib/source-map-generator.js:73:17
10:10:57      at BasicSourceMapConsumer.SourceMapConsumer_eachMapping [as eachMapping] (/home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/source-map-js/lib/source-map-consumer.js:155:7)
10:10:57      at Function.SourceMapGenerator_fromSourceMap [as fromSourceMap] (/home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/source-map-js/lib/source-map-generator.js:49:24)
10:10:57      at MapGenerator.generateMap (/home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/postcss/lib/map-generator.js:101:37)
10:10:57      at MapGenerator.generate (/home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/postcss/lib/map-generator.js:85:19)
10:10:57      at new NoWorkResult (/home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/postcss/lib/no-work-result.js:33:46)
10:10:57      at Processor.process (/home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]/node_modules/postcss/lib/processor.js:51:14)
10:10:57      at runPostcss (file:///home/jenkins/workspace/Geiger/geiger-review/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-e4a495ce.js:287:6) {
10:10:57    code: 'PLUGIN_ERROR',
10:10:57    loc: { column: undefined, line: undefined },

Is there another change or upgrade I'm supposed to do as well?

[ai]

@kaiyoma thanks for the report. We forgot one more all of source-map-js. I am going to fix it ASAP.

[kaiyoma]

@ai Thanks for all the debugging tips! I narrowed down the issue to swagger-ui-react and just filed an issue against them: swagger-api/swagger-ui#9946

[ai]

Try to reproduce this error with minimum amount of plugins.

This error happen because your AST is broken. Very likely that it was broken by some PostCSS plugin (previous PostCSS just missed that fact).

[kaiyoma]

My Vite config already has the bare minimum set of plugins:

plugins: [react()],

What else should I check? I'm not sure what your AST is broken means in this context. Happy to provide more info (version numbers, configs, etc) to troubleshoot this.

[ai]

I am talking about PostCSS plugins, not Vite plugins.

[kaiyoma]

AFAIK we have not configured any postcss plugins. We don't use postcss directly, but we have to install it because it's a required dependency of other things we use.

[ai]

Seems like it is even more interesting case. Very likely that some other CSS tool broke source map.

Let’s debug. Can you open /home/jenkins/workspace/Geiger/geiger-upgrade-deps/node_modules/.pnpm/[email protected]/node_modules/source-map-js/lib/source-map-generator.js, put console.log(prev) on line 100, like this:

  generateMap() {
    if (this.root) {
      this.generateString()
    } else if (this.previous().length === 1) {
      let prev = this.previous()[0].consumer()
      prev.file = this.outputFile()
+    console.log(prev)
      this.map = SourceMapGenerator.fromSourceMap(prev)

and check out previous source map content.

[kaiyoma]

I did some digging and found that we use postcss-less as a custom syntax for stylelint, which is why we have postcss in our dependencies list to begin with. Other than that, we don't use PostCSS directly, though it is an indirect dependency of a lot of our other libraries/tools from npm.

[kaiyoma]

Let’s debug. Can you open /home/jenkins/workspace/Geiger/geiger-upgrade-deps/node_modules/.pnpm/[email protected]/node_modules/source-map-js/lib/source-map-generator.js, put console.log(prev) on line 100, like this:

I don't see this code locally. If I open that file and search for generateMap nothing is found.

[ai]

Dirs starting from . is hidden. Try to enable Showing hidden files in your file manager.

[kaiyoma]

No I mean I found the file just fine. That code you referenced isn't inside of it.

[ai]

Sorry, this file: /home/jenkins/workspace/Geiger/geiger-upgrade-deps/node_modules/.pnpm/[email protected]/node_modules/postcss/lib/map-generator.js

[kaiyoma]

Okay, much better. Output is huge: debugging-output.txt

[ai]

No, we can’t debug on such big project.

1. Start from removing all files until you have 1-2 CSS files and error is still reproducing.
2. Then try to convert LESS to CSS and remove postcss-less. It could generate broken source maps.

[strmer15]

Oh, wait I got mixed up - the line where the postcss process is happening is in the vite bundle, but that's only because it's bundling dependencies. It's actually happening from postcss-import - https://github.com/postcss/postcss-import/blob/d8a9f21f0f62077d05d9b60680cd50e3546fdf6e/lib/process-content.js#L41.

Apparently it's using null as the default, so the change to not only check for undefined broke it.

[ai]

Yes, we are starting NoWorkResult for now. But the question is why it doesn’t work in this case.

Something is broken when we are trying to combine previous source map (from Sass or Less) with PostCSS 1-to-1 source map (source map of nothing was changed).

Are you using the latest 8.4.33 version of PostCSS (where @romainmenke fixed one bug with NoWorkResult)?

[strmer15]

Yes, we are starting NoWorkResult for now. But the question is why it doesn’t work in this case.

It's because when we do imports of other CSS files from SASS, the postcss-import plugin is being triggered, but Vite doesn't use the syntax.parse or parser options when invoking it (looks like that's happening in https://github.com/vitejs/vite/blob/06494443194763d6dd125740961cec82dd9a29d6/packages/vite/src/node/plugins/css.ts#L1200).

Because of that, the the parserList used by the runPostcss function just has a single null parser which is sent to the postcss process function. And, because that change was made, postcss used to return LazyResult but now returns NoWorkResult. When I have it return LazyResult again, no error is thrown.

Something is broken when we are trying to combine previous source map (from Sass or Less) with PostCSS 1-to-1 source map (source map of nothing was changed).

Are you using the latest 8.4.33 version of PostCSS (where @romainmenke fixed one bug with NoWorkResult)?

Yes, the only reason this is happening is because I'm using the 8.4.33 postcss version that made the change - it was a subdependency that got installed and then broke my Vite build.

[ai]

And, because that change was made, postcss used to return LazyResult but now returns NoWorkResult

Yes, I understood that. But why we have a problem with NoWorkResult.

Can you create a small reproduction example for me to look what is in previous source map and why it is not working with 1-1 source map.

[strmer15]

And, because that change was made, postcss used to return LazyResult but now returns NoWorkResult

Yes, I understood that. But why we have a problem with NoWorkResult.

Ah, sorry, I misunderstood. Thanks for being patient with me.

Can you create a small reproduction example for me to look what is in previous source map and why it is not working with 1-1 source map.

Yeah, it might take me a little bit to find some time - I'm guessing it would just involve using vite with a single SASS file that imports a CSS file.

[romainmenke]

Thank you for the repo's @silverwind and @strmer15, those allowed me to investigate further.

A minimal reproduction based on swagger-ui.css : https://github.com/romainmenke/issue-1914-sourcemaps

This is unrelated to :

• postcss-import
• vite
• ...

It is however related to the recent changes and also to those specific CSS files and their sourcemaps.

If I use any sourcemap I generate myself with PostCSS I do not get the error.

[romainmenke]

It could help to have a smaller sourcemap that also triggers the issue.
swagger-ui.css is way to massive to analyse.

It would be good to understand in detail why one sourcemap errors and another is just fine.

---

It might be interesting to clone swagger-ui and remove a bunch of their style source code to reduce the size and generate a minimal version that errors that way.

https://github.com/swagger-api/swagger-ui/blob/master/package.json

[ai]

Here is a good tool to debug source maps
https://sokra.github.io/source-map-visualization/

Maybe input source map from previous step has missing parts (especially start/end)?

The 1-to-1 source map of NoResult covert CSS from first byte to last. When source map of Result covers only parts with non-whitespace symbols. Maybe, the issue is when Vite try to combine, for instance, enf-of-file \n from PostCSS’s source map with nothing in previous source map (not a problem in the between, but could be a problem on start/end).

[romainmenke]

It's not related to vite.
It isn't even related to postcss.

This is a bug in source-map-js or in the producer of the sourcemaps for things like swagger-ui.

Reproduction of the error in the tests of source-map-js:

var util = require("./util");
var SourceMapGenerator = require('../lib/source-map-generator').SourceMapGenerator;
var SourceMapConsumer = require('../lib/source-map-consumer').SourceMapConsumer;

exports['test .fromSourceMap with only a single field in the last mapping entry'] = function (assert) {
  var map = SourceMapGenerator.fromSourceMap(
    new SourceMapConsumer(`{
	"version": 3,
	"file": "swagger-ui.css",
	"mappings": "AAAA,iBAWE,uBAFA,sBACA,kBAEA,oCAVA,eACA,gBAEA,iBAEA,kBAKA,CAEA,wBAEE,eACA,iB",
	"sources": [
		"webpack://swagger-ui/./src/style/_buttons.scss"
	],
	"sourcesContent": [
		".btn\\n{\\n  font-size: 14px;\\n  font-weight: bold;\\n\\n  padding: 5px 23px;\\n\\n  transition: all .3s;\\n\\n  border: 2px solid $btn-border-color;\\n  border-radius: 4px;\\n  background: transparent;\\n  box-shadow: 0 1px 2px rgba($btn-box-shadow-color,.1);\\n\\n  &.btn-sm\\n  {\\n    font-size: 12px;\\n    padding: 4px 23px;\\n  }\\n}\\n"
	],
	"names": [],
	"sourceRoot": ""
}`));
  util.assertEqualMaps(assert, map.toJSON());
};

FAILED ./test-postcss-1914: test .fromSourceMap with only a single field in the last mapping entry!
Error: 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.

The cause is the last entry in mappings : iB

That entry doesn't have any line/column numbers and source-map-js errors when it encounters this.

---

I don't know why LazyResult doesn't hit the same code paths, but this issue happens outside of the control of postcss.

[romainmenke]

Also seems to be an old issue : mozilla/source-map#385

[silverwind]

Why did postcss 8.4.32 and earlier not raise this error? Should previous behaviour be restored for compatibility?

[romainmenke]

8.4.32 and earlier had a bug that caused the previous sourcemaps to be discarded/ignored for NoWorkResult.
This was fixed in 8.4.33.

But unfortunately this surfaces issues when reading/writing those previous sourcemaps would give errors.

I suspect that LazyResult mutates the previous sourcemap sufficiently to make the errors go away, but this code is extremely complicated and very hard to read/follow.

---

I don't fully understand the root cause yet.
Is this ultimately a bad sourcemap file or a bug in a sourcemap parser/generator?

So I don't have a strong opinion on how to move forward, but that also isn't up to me :)

[silverwind]

I guess there should at least be an option to ignore broken sourcemaps because they are not in control of the author in cases like with this swagger-ui dependency.

[ai]

You can ignore previous source map by map: { prev: false } option

[silverwind]

You can ignore previous source map by map: { prev: false } option

Unfortunately, setting these map options is not possible with vite currently as vite hardcodes them.

[romainmenke]

Looking at the other side of the chain now and it seems that postcss-loader is the emitter of the bad sourcemap.

Edit :
With a different source postcss-loader does produce a good sourcemap, so the previous output might have been a sourcemap that was passed to postcss-loader.

---

When I look at the tests for sourcemaps in that package I immediately see that they are testing against NoWorkResult. This always has a sourcemap from start to end and doesn't actually have detailed sourcemaps per AST node.

The irony here is that this all started because of subtle differences between NoWorkResult and LazyResult and that it isn't obvious when you will have which mode.

I really fear that many parts of the PostCSS ecosystem have subtle bugs because of this dual mode.

[silverwind]

In bundler cases where postcss config is accessible like with webpack, one can workaround via map: false. In case of vite it seems impossible, so I had to override the postcss version via package.json there.

[Machineric]

Has anyone solved this issue in case of Vite?

[romainmenke]

@ai, can we revert #1908 until a fix for the underlying issue is found?

[kaiyoma]

Please send PR to source-map-js.

If I will hide this issue, nobody will fix it never.

source-map-js hasn't had a release in over 2 years, so it seems unlikely that this will be successful. I would also vote for a revert.

[silverwind]

Vite issue: vitejs/vite#16164

[Machineric]

Has anyone solved this issue in case of Vite?

In your package.json, with npm:

  "overrides": {
    "postcss": "8.4.32"
  }

For a better workaround, vite needs to allow user to pass in {map: false} to postcss, but this is currently not possible because of vite's hardcoding of postcss.process options.

Oh, I miseed you mentioned this workaround right above my post.
Thanks for the help!!!

[romainmenke]

Thank you @ai 🙇

[silverwind]

You are waiting for free support for your commercial projects from open source maintainers and do not want to spend a little of your time to help us in return.

I support both open and closed source projects that were affected by this bug. In fact, I plan to still contribute that options fix to Vite. It's just the original issue in the generation here seemed to "deep" to me and as indicated in 7rulnik/source-map-js#18 (comment), not even the autor of the package understands the issue.

Instead, you are suggesting bad and dangerous hacks (disabling source map will decrease DX) to hide the error instead of debugging it.

TBH, I don't think a CSS source map has ever been useful to me. For JS, I fully support them, but CSS is a simple enough language that source maps are generally not not needed.

[kaiyoma]

@kaiyoma thanks for the report. We forgot one more all of source-map-js. I am going to fix it ASAP.

Gotcha. No rush, take your time. I can test again when there's a new version.

[ai]

Fixed b5bd92c

[ai]

The second fix was released in 8.4.37.

Please try.

[kaiyoma]

The second fix was released in 8.4.37.

Please try.

Yes, I'm still seeing this error:

  VITE v4.5.0  ready in 2787 ms

  ➜  Local:   http://localhost:3001/
  ➜  Network: use --host to expose
  ➜  press h to show help
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.

Vite is no longer crashing, which is good, but the error message is still appearing.

[ai]

Yes, we moved error to a warning since the previous source map is still broken and PostCSS can generate 100% correct source map.

[kaiyoma]

Do we need a change to Vite then, to remove the warning? I remember someone else was talking about submitting a PR to Vite.

[ai]

Do we need a change to Vite then, to remove the warning?

No, you need to fix source map in CSS dependency.

I remember someone else was talking about submitting a PR to Vite.

Nope, that PR just allow disabling source map. It is decreasing DX just to hide issue, not fix it.

[kaiyoma]

@ai How are we supposed to know where the issue is? This warning message is very vague and not helpful.

[ai]

It is not easy to detect who broke source map. I can say only that it is:

1. Some tool before PostCSS in webpack pipeline
2. Or more likely the webpack of some CSS from node_modules.

I don’t have motivation of helping find the other tools issue. If you have such, both PostCSS and source-map-js so open for PRs. What solution do you suggest?

[kaiyoma]

TBH I still don't understand the issue here. We don't use CSS source maps, we don't use webpack, and I don't quite understand the point of CSS source maps in the first place, since the CSS class names aren't translated during the build.

[ai]

1. Do you import some CSS from node_modules?
2. You can disable source map and you will not have warning. If you bundler explicitly told to PostCSS to generate source map, of course, PostCSS will assume that source map can be useful. Software can’t read your mind to show only relevant information. We can add many heuristics to detect some cases, but it is not my priority (and will not be useful here).

[kaiyoma]

Yes, we import CSS from node_modules. How do I disable CSS source maps? I don't see any option to do that here: https://postcss.org/api/#sourcemapoptions

[romainmenke]

Can you share which CSS is imported?
I know that swagger-ui publishes CSS which has this issue, knowing of other libraries/frameworkers might allow us to spot a common factor.

[ai]

How do I disable CSS source maps?

It depends on how do you use PostCSS. Do you use it as direct JS API or as part of some bundler like webpack or Vite?

[kaiyoma]

We don't use it directly. I believe it's in our app because we use LESS and it's a requirement of that. Our app is built with Vite.

[ai]

I don't see a specific option in Vite, maybe you need to ask Vite community.

What CSS do you import?

[kaiyoma]

We import CSS from any npm library that has React components (Ant Design, react-grid-layout, swagger-ui-react, etc). We also import CSS from a lot of packages in our own monorepo.

[kaiyoma]

I don't see a specific option in Vite, maybe you need to ask Vite community.

I see a config option for specifying a PostCSS config: https://vitejs.dev/config/shared-options.html#css-postcss

I just don't know what options to pass here.

[ai]

map: false, but I think somebody told above, that Vite override it

[kaiyoma]

So is there any way to disable this warning via PostCSS options? I don't find it helpful, so disabling it would also be an option.

[ai]

The best way to deal with warming:

1. Disable CSS import one by one
2. When warning will be disappeared, your found the source of issue
3. Report the issue to the library, send PR