Semantic highlighting: Non-explicit readonly properties not shown as such

🔎 Search Terms

readonly, readonly properties

🕗 Version & Regression Information

Nothing to put in here, has never worked, I don't think.

Might be a language server issue, idk

⏯ Playground Link

https://www.typescriptlang.org/play#code/CYUwxgNghgTiAEYD2A7AzgF3lAXPA3gFACQcUwqEAntgEZigBmeKArgLa0gyEC+hUAHRR6TQqEiwEydFlp4ASiHKUqAHiLERDEM3htO3PgD5CtYaN3jw0OIlSZEefPDIUU1Ojr0YYrBLzwAD4ErsruntpMeIxQEGgBhGAW3oQAlozwABTJUboAlAQkuZaMfEnQaGjwACJFxADmIFh5jFmFmqTNrDAo8ACMJPz8ErbSDljAeDXiKWJAA

💻 Code

In this example, there are 4 variables, all with a readonly property called abcdef, only the first one is registered by the IDE as being readonly, even though they are.

declare const a: {
	readonly abcdef: number
}
a.abcdef
declare const b: Readonly<{
	abcdef: number
}>
b.abcdef
declare const c: { readonly abcdef: true } | { readonly abcdef: false }
c.abcdef
if (c.abcdef) {
	c.abcdef
}
class D {
	get abcdef() {
		return 1
	}
}
declare const d: D
d.abcdef

🙁 Actual behavior

This is an IDE issue regarding code highlighting. When a property is readonly, but not explicitly so, it doesn't show up as a readonly property. TypeScript knows it's readonly, but the syntax highlighting doesn't always match it, which can be a bit confusing, just like if consts didn't always have the different highlighting. It's a lot nicer when you can always immediatly tell when something is readony, not by having to test it out and it makes it a lot more readable.

🙂 Expected behavior

All the properties should be registered as readonly, in the case of VSCode, the same colour as constants

Additional information about the issue

No response

Reproduce the semantic-highlighting behavior using the linked TypeScript Playground example and inspect the corresponding VSCode highlighting. Compare the four readonly-property cases, including Readonly, unions, and the getter, and consider the issue done when every readonly property is highlighted consistently as expected.