DTS Bundling not exporting previously available interfaces and types

[AndrewLeedham]

Describe the bug

Since @vanilla-extract/[email protected] I cannot compile Vanilla Extract types with tsc. The issue seem to step from the bundling of dts files, as interfaces like AllQueries are no longer exported, so the TypeScript compiler throws the following error:

Exported variable 'exampleRecipe' has or is using name 'AllQueries' from external module "file:///node_modules/@vanilla-extract/css/dist/vanilla-extract-css.cjs" but cannot be named.

This happens when composing types like StyleRule which are exported but use interfaces that aren't.

Reproduction

https://www.typescriptlang.org/play?ts=5.1.3#code/JYWwDg9gTgLgBAbzgZRgTwDYFMBKBXbOAXzgDMoIQ4ByAAQDcBDAO2Aw0YFosAPGKRgGMYAekEBncdQDcAKFmhIsRHChZBwMFmJkKVOk1bsuvfkNFqNWqXNmCIzcfFIRBecQC4U6bPmwBtanEsbGFoKQBdOABeRFk4GgAyDxc3cU56YHFgACNsai8EeIS4ewxoL2o8vCxqYqJZBtleJXh7R3heRnBfdU1tWMt+gAoihJzGYMLihLKKmjUAE2oAGnq1hKYoYBYYTziSuEWssA40acPx8sEAawvLhOPxU8ZzmjzXG9WZkqINy+owGYGCBWE4H1uBQODyOJzOlSBIOYYIhXx+CT+6LIrnc9wewVCMHCeJhADpyal3P8Hg0aT9MRjGgBKaRAA

System Info

I cannot run that in the TS playground, but I am seeing the issue locally with:

  System:
    OS: macOS 13.3.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 267.59 MB / 16.00 GB
    Shell: 5.8 - /usr/local/bin/zsh
  Binaries:
    Node: 16.18.0 - ~/.nvm/versions/node/v16.18.0/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.6.3 - ~/.nvm/versions/node/v16.18.0/bin/npm
  Browsers:
    Safari: 16.4
  npmPackages:
    @vanilla-extract/esbuild-plugin: 2.2.2 => 2.2.2 
    @vanilla-extract/vite-plugin: 3.8.2 => 3.8.2 
    esbuild: 0.17.19 => 0.17.19 
    rollup: 2.79.1 => 2.79.1 
    vite: 3.2.7 => 3.2.7

Used Package Manager

yarn

Logs

Exported variable 'exampleRecipe' has or is using name 'AllQueries' from external module "file:///node_modules/@vanilla-extract/css/dist/vanilla-extract-css.cjs" but cannot be named.

Validations

• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[mrm007]

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.

[AndrewLeedham]

@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?

[AndrewLeedham]

@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.

[askoufis]

@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.

[AndrewLeedham]

@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.