ESM TypeScript Module Resolution breaks sprinkles type definitions

Describe the bug

We are building a component library using Vanilla Extract and Sprinkles. We have been using CommonJS module resolution via moduleResolution: 'node' in tsconfig.json. We would like to migrate to ES Module resolution via moduleResolution: 'node16' in tsconfig.json. We are encountering issues with the Sprinkles package where the types generated via ES Module resolution are not specific, when they are when using CommonJS module resolution.

When using moduleResolution: 'node', our type definitions look something like this:

dist/sprinkles.css.d.ts

export declare const sprinkles: import("@vanilla-extract/sprinkles/dist/declarations/src/createSprinkles").SprinklesFn<[{
    conditions: {
        defaultCondition: "mobile";
        conditionNames: ("mobile" | "tablet" | "desktop")[];
    };
    styles: {
        display: {
            values: {
                block: {
                    defaultClass: string;
                    conditions: {
                        mobile: string;
                        tablet: string;
                        desktop: string;
                    };
                };
                flex: {
                    defaultClass: string;
                    conditions: {
                        mobile: string;
                        tablet: string;
                        desktop: string;
                    };
                };
                none: {
                    defaultClass: string;
                    conditions: {
                        mobile: string;
                        tablet: string;
                        desktop: string;
                    };
                };
            };
        };
    // ...
}

However, when we use moduleResolution: 'node16', the type definition looks like this:

dist/sprinkles.css.d.ts

export declare const sprinkles: any;

Reproduction

https://github.com/davidhousedev/vanilla-extract-esm-issue-reproduction

System Info

System:
    OS: macOS 11.6.6
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 311.74 MB / 64.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.15.0 - ~/.nvm/versions/node/v16.15.0/bin/node
    Yarn: 1.22.18 - ~/.nvm/versions/node/v16.15.0/bin/yarn
    npm: 8.5.5 - ~/.nvm/versions/node/v16.15.0/bin/npm
  Browsers:
    Chrome: 102.0.5005.115
    Firefox: 101.0
    Safari: 15.5
  npmPackages:
    @vanilla-extract/sprinkles: ^1.4.1 => 1.4.1 
    @vanilla-extract/vite-plugin: ^3.2.1 => 3.2.1 
    vite: ^2.9.9 => 2.9.13

Used Package Manager

yarn

Logs

No response

Validations

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

[pkieltyka]

@davidhousedev @benjervis hey all, just wanted to mention this issue still exists with typescript 4.8.4, @vanilla-extract/sprinkles, tsconfig “node16” module resolution and … drumroll… pnpm. The combination of these modern tools causes the error:

src/shared/style/IconSprinkles.css.ts:30:14 - error TS2742: The inferred type of 'IconSprinkles' cannot be named without a reference to '../../../node_modules/@vanilla-extract/sprinkles/dist/declarations/src/createSprinkles'. This is likely not portable. A type annotation is necessary.

30 export const IconSprinkles = createSprinkles(ResponsiveIconProperties)

the call to createSprinkles is unable to infer the SprinklesFn type. Also see https://github.com/microsoft/TypeScript/issues/47663 for related reports in other projects using pnpm + tsc + esm.

I do believe similar to the PR https://github.com/vanilla-extract-css/vanilla-extract/pull/890 if you just export the SprinklesFn type, then typescript will be able to find and infer the type.

[otaviomad]

I can confirm that this is still an issue. @phil-lgr’s fix does work. RuntimeFn is not seen as an export from where the declaration tries to import it.

Highlighting does work before the build, but breaks after it. I suppose it’s because the types.d.ts file isn’t defined in the exports key on the package.json for the recipes package. This means that defining something that has the RuntimeFn type is only possible through the ReturnType of the recipe function.

Again, adding RuntimeFn as an export to index.d.ts just works.