Hi @AndrewLeedham, this looks like a quirk of the TypeScript compiler. We wouldn't want to expose APIs that we'd like to reserve the right to change in the future. However, you can work around this using the satisfies operator:

const focus = {
  '&:focus-visible': {
    color: 'blue'
  }
} satisfies StyleRule['selectors'];

Does this work for you? I realise this is just an example and might not be the same as your production code.

@mrm007 thanks for the workaround. You are right this is a minimal repro. The actual use case is using helper functions which return those objects. I could probably use satisfies and infer return types, but this seems like quite a significant gotcha. Composing types at least in our codebase is very common, and we are not yet on TS 5 (although I will work on upgrading soon).

Perhaps I exported too much, I was just concious that other functions may have similiar issues. But I could just export AllQueries as its constituent parts are already exported?

@mrm007 another case where keeping raw typing around doesn't quite work is conditionally modifying a styles object: TS Playground Link

I updated the original PR to just export AllQueries.

@mrm007 another case where keeping raw typing around doesn't quite work is conditionally modifying a styles object: TS Playground Link

I updated the original PR to just export AllQueries.

Not sure what the a is doing in your selectors object, but the satisfies isn't helping here:

const selectors = {
  'a': {
    color,
  }
// Keeps the type as narrow as possible
} satisfies StyleRule['selectors'];

if (color) {
  // selectors is not a StyleRule['selectors'], so it doesn't know about the `a:hover` property
  selectors['a:hover'] = {
    color: hoverColor
  }
}

By using an explicit type annotation, you can conditionally mutate the selectors object. You do unfortunately need to annotate the return type as well.

@askoufis you are right I borked the syntax a little there, maybe something more like this. However, using an explicit type annotation is what caused the issue with recipes, so yes this would fix that example but re-introduce the issue from the first one.