Skip to content

Fix Input#origin() mixing null and undefined for unmapped end position#2106

Merged
ai merged 1 commit into
postcss:mainfrom
chatman-media:fix-origin-unmapped-end-position
Jun 30, 2026
Merged

Fix Input#origin() mixing null and undefined for unmapped end position#2106
ai merged 1 commit into
postcss:mainfrom
chatman-media:fix-origin-unmapped-end-position

Conversation

@chatman-media

Copy link
Copy Markdown
Contributor

When the end position passed to origin() isn't covered by the source map, originalPositionFor() comes back with line/column set to null instead of just not having a mapping. endLine ends up null in that case, but endColumn was being built as to && to.column + 1, which because of precedence is actually to && (to.column + 1), so null silently becomes 1. You can end up with something like { endColumn: 1, endLine: null }, which is inconsistent with how the rest of the function treats an unresolved position (both stay undefined).

Looks like #2036 fixed the off-by-one for the case where the end position does resolve, but didn't account for it not resolving at all.

Guarded to the same way from already is a few lines above, and added a test that reproduces it with a source map that doesn't cover the requested end line.

When the requested end position has no mapping in the source map,
originalPositionFor() returns an object with line/column set to null
rather than omitting them. endLine picked that null up correctly, but
endColumn was computed as `to && to.column + 1`, which due to operator
precedence is `to && (to.column + 1)`, turning null into 1. So callers
could get back { endColumn: 1, endLine: null }, which doesn't match
how every other unmapped case in this function behaves (undefined for
both). Looks like the +1 fix in postcss#2036 covered the mapped case but not
this one.

Guard `to` the same way `from` already is, so an unmapped end position
just stays undefined.
@ai ai merged commit 3298727 into postcss:main Jun 30, 2026
9 checks passed
@ai

ai commented Jun 30, 2026

Copy link
Copy Markdown
Member

Thanks!

Do you think we should release it right now or the user case is pretty rare (so we will wait more features to release together)?

@chatman-media

Copy link
Copy Markdown
Contributor Author

Up to you — it's not a long-standing bug, more a fresh regression from #2036/8.5.16, so I'd lean toward not sitting on it too long rather than batching it. Whenever a reported range's end falls outside sourcemap coverage, anything reading endColumn as a number gets a bogus 1 with no matching endLine — not sure how rare that is in the wild, but it's not a contrived case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants