What is checked

The syntax is not TypeScript, so the package owns a parser and a virtual-file layer — the same way JSX is usable because somebody wrote the parser for it. That layer is what buys the checking: a fault in a block arrives as an ordinary tsc diagnostic, on the character you wrote, in your own file.

Running it

The checker takes a project, not a file — every block becomes a virtual file and the whole program goes to tsc once, which is what makes a report land on your own character:

npx ramonda-css                 # the `tsconfig.json` beside you
npx ramonda-css app/tsconfig.json

There is no check verb: the bare command IS the check, and format, lint, codegen and explain are the ones that are not. It exits non-zero when it reports anything, so it is a CI step as it stands.

A build stops on every CSS rule below, and it does not run the type check. What only the types catch — a match key its subject can never be, or a value of the subject with no arm — is reported by this command and by your editor, not by Vite or esbuild. Run it in CI beside the build.

What your editor tells you

• A property that does not exist is TypeScript's own did you mean, on the property.
• A value the property does not take is reported the same way, with the values it does take. A property whose grammar admits a name nobody can judge — animation-name: slidein is yours to pick — is left alone. A url() or a quoted string in the value does not make it one: cursor: url(a.cur), pointerr is still reported, on pointerr.
• A runtime value in a declaration is refused — color: $(this.brand) — and the message names the two things to use instead: a match for a value that is one of a few, and @@property for one that really comes from data.
• An expression is checked in the scope where it was written, wherever $( … ) is allowed: a condition, a spread, a match subject. this.loud resolves to the field beside it, because the expression stays where you put it.
• A condition or a selector spelled two ways is reported, with the spelling to use. @media (min-width:40rem) and @media (min-width: 40rem) are the same CSS, so writing both is writing two of what should be one thing.
• A quoted value on a property with no place for a string is reported. Your editor completes a value from a real union the way it completes any string literal, so color: "yellow" is an easy thing to end up with — and it compiles, ships color:"yellow", and is dropped by every browser. content: "hi" and font-family: "Brand" are correct CSS and stay silent, because the question is asked of each property's own grammar.

One spelling

Two spellings of the same CSS are two things to search for and two to keep in step. Where a declaration, a condition or a selector has a canonical form, the other one is reported and ramonda-css format writes the canonical one:

const card = @@(
  COLOR: red;
  @media (min-width:40rem) { color: blue; }
);

Both of those are correct CSS — a browser reads COLOR and color as one property, and a media query with no space after the colon is the same query. What they cost is a second thing to grep for.

CSS does not mind either. Your repository does.

Inside a named block, the vocabulary is its own

@@keyframes, @@font-face and @@property each hold something different from an element's rule, and the check follows that:

An expression may not go in one of these at all: these name something the whole stylesheet uses, and there is no element for a value to come from.

A media feature that will never match is the row worth pausing on, because it is not invalid CSS. A browser reads @media (min-widht: 40rem), keeps the rule, and never matches it — so every declaration inside is inert and nothing else has any reason to complain.

When a rule is wrong

Every rule here fails the build. There is no warning level, and that is deliberate: a warning nobody must act on is a warning nobody reads.

So there is one way to say I looked at this and it stays:

/* ramonda-css-ignore a vendor stylesheet defines this one */
display: flexx;

It covers the next line only, so it cannot creep past what you looked at. It works in a // comment too, for a finding about the block itself rather than about a line in it.

A reason is required. A directive with nothing after it is refused, and does not exempt the line below it either:

a ramonda-css-ignore with no reason after it is a silence, not a record.

And every one is printed on every run, whether or not anything failed:

[ramonda-css] 1 `ramonda-css-ignore`, honoured:

  src/Card.tsx:12  a vendor stylesheet defines this one

That is what makes it a record rather than a silence. A reason that has stopped being true is one somebody meets, instead of one they would have to go looking for.

What your project adds to that

Everything above is CSS being checked against itself, and it needs no config. A ramonda.css.ts adds reports that are yours rather than CSS's — a unit this project does not use, a value outside a list it gave, a shorthand it switched off, a colour written out where it takes colours from tokens, a $ path it does not declare. Each is a row in the table below, and each fails the build the same way.

If that file cannot be read, your editor says so on the block. The completions keep working, but nothing is being checked against rules that did not load, and a green file would be a claim the tool cannot support:

[config-not-read] … does not parse: TS1136: Property assignment expected. Until it reads, none of this project's rules are running — this block is not being checked against them, and a build will refuse before it gets here.

Every rule

A typo in one of these ids is caught too: writing unknown-unti in ramonda.css.ts tells you so, and names the one you meant.

82 rules. Every rule that reads a block fails the build. The 8 marked type check need TypeScript's answer about a type, so the editor and ramonda-check report them and the build — which does not type-check — does not. Each is a key you can switch off, except block-in-a-template and block-refused: the build refuses those whatever a config says, so switching one off would only quiet the editor.

Next

• The config file — switching a rule off, and making the rest stricter than CSS is.
• Tooling — what your formatter and linter can and cannot read.