Lint does only process default context in resolver

[xkrys]

Versions

• @terrazzo/cli@2.4.0

Node.js version

22.22.3

OS + version

macOS 26.5.1 (25F80)

Description

When running cli lint with a multi context resolver the lint only verify the default or first context for each modifier.

Reproduction

Create a broken token reference in the second and non-default context of a modifier. The will pass.

Expected result

Every single context of every modifier should be linted

Extra

• I’m willing to open a PR (see CONTRIBUTING.md)

[drwpow]

Good catch—yeah this is sort of a hard problem to fix at the moment due to some decisions made regarding linting & validation.

At the time, it seemed like a good idea to combine the idea of linting & validation together into a single concept—it lets folks conform to the spec by default, or provide per-token modifications as they need to (more in service of incrementally adopting the spec from their custom setup). But it poses a problem with resolvers because individual permutations often get instantiated in other plugin steps other than lint.

Three solutions I can think of are both breaking changes, and all are hard to make right now:

1. We revert the decision to combine validation & linting, and have an internal concept of validation that happens as part as resolution. However this only solves a small subset of the issues you mentioned—it only ensures that the core lint rules get run, but all custom rules still wouldn’t work in resolvers which may defeat the point of linting.
2. We rework the lint API to deal with pre-resolved token sources, rather than resolved tokens. This means the lint stage doesn’t know if tokens are resolved, or how they fit into the greater context. But is more akin to traditional linting tools which take this approach.
3. We change the stage at which lint runs, such that it will run any time a new permutation is encountered (I’m a bit less enthused about this, because it still means linting will happen as part of a build step, which is a bit backwards in my opinion)

Of the three approaches, #2 probably seems the best way forward, but is still a breaking change from the current lint setup which tries to act on the final set of tokens, rather than treating them as source files. But any of these approaches will unfortunately have to wait until 3.0 to roll out. (Also note that #2 can still work on “virtual” or in-memory tokens, “sources” just simply means “as-written” whether those are files or in-memory)