Failing tests in non-TS app due to undefined vars

[epavletic]

I’ve run into something like a brick wall while introducing @vanilla-extract at work. Some background on what I’ve been fiddling with, in case I’m doing something that’s less than ideal:

I am building a new component library in TS, with Vanilla-extract. It is meant to be consumed in a non-TS application, and based on advice from Matt I’ve opted to just export the result of building the library with tsc and let webpack in the consuming non-TS application bundle it.

On the library side, I have the following setup:

A themeContract is created and exported:

// src/themes/vars
import { createThemeContract } from '@vanilla-extract/css';

const themeTokens = {
  colors: {
    links: {
      default: null,
      focus: null,
    },
    // some other stuff here
  },
} as const;

export const vars = createThemeContract(themeTokens);

One thing to note is that we also export/expose the above:

// srs/index.ts
export { vars } from './themes/vars.css';

It’s then used to create a couple ot themes (there’s about 8 of them at the moment…):

// src/themes/theme1/theme.css.ts
import { createGlobalTheme } from '@vanilla-extract/css';
import { vars } from '../vars.css';
import '../globalStyles.css'; // some reset stuff using globalStyle()

const themeTokens = {
  colors: {
    links: {
      default: '#2b75bb',
      focus: '#2668a6',
    },
  },
  // etc.
};

export default createGlobalTheme(':root', vars, themeTokens);

The themes are consumed by a ThemeProvider that basically recieve a brand prop, and based on that fetches the correct theme:

// src/components/themeprovider/ThemeProvider.tsx
import { ReactNode, useEffect } from 'react';

export type ThemeProviderTypes = {
  brand: string;
  children: ReactNode;
};

export const ThemeProvider = ({ brand, children }: ThemeProviderTypes) => {
  useEffect(() => {
    const loadTheme = async (brand: string) => {
      try {
        await import(/* webpackChunkName: "[request]" */ `../../themes/${brand}/theme.css`);
      } catch () {
        console.warn(`The \`ThemeProvider\` failed to properly fetch the global CSS file for \`${brand}\`. Falling back to the default theme.`);
        await import(/* webpackChunkName: "default-theme-css" */ `../../themes/default/theme.css`);
      }
    };

    loadTheme(brand);
  }, [brand]);

  return children;
};

The ThemeProvider is then used to wrap the entire consumer application, providing it with the correct css-file with all the custom properties. Since we export vars from the library, it is also available to use in the consumer application:

// some/file/in/consumer/app.jsx
import { vars } from '@company/componentLibrary';

const Component = styled('div')`
  color: ${vars.colors.links.default};
`;

Now to the issue: The above works just fine in the browser – then correct theme file is fetched, and using vars to set colors in components works as you’d expect. It explodes in Jest/JSDOM though:

● Test suite failed to run

    TypeError: Cannot read property 'colors' of undefined

      35 |
      36 | const Component = styled('div')`
    > 37 |   color: ${vars.colors.links.default};
         |                 ^

I am not sure how to address this: One thought that went through my head was that ”of course vars isn’t defined – it only gets defined when the ThemeProvider does its thing. We need to wrap the component that uses vars in a ThemeProvider in the test”. That did not work though. I’ve added @vanilla-extract/babel-plugin to the Jest setup in the consumer application. Am I bitten by the fact that Jest can’t handle the TS in the component library (since I am now in a js context and the webpack plugin is not running in the tests)? Or is the babel plugin supposed to handle this for us? Timing issue 🤔

Some pointers would be deeply appreciated, feel free to suggest a different take on the whole setup if that is what is wrong as well – this is the final piece needed to introduce @vanilla-extract to our codebase, and I’d love to be able to nudge it over the finish line. 🙏

[mattcompiles]

Hey bud. It's very hard to give much advice here without a reproduction of the issue. If you can reproduce it then we can take a look. However, I'd say your setup looks good to me.

The only advice I can give is, from a jest perspective vanilla is really just normal code. There's no magic going on. The babel plugin does a very small transform but if that was the issue you wouldn't get an error like you're getting. I'd be debugging your tests and seeing what is going on inside your library when you run a failing test. Running jest through the node debugger in vscode is quite easy now, that's my go-to for this kinda stuff.

[epavletic]

Hey @noahub,
We’re not using Next.js, so I can’t vouch for my approach working in that environment – with that said, what worked for me in the end was using identity-obj-proxy, something I picked up from the Jest docs for mocking CSS Modules. The actual config being:

moduleNameMapper: {
  '(?<!.vars)\\.css$': `identity-obj-proxy`,
}

As for using @vanilla-extract/jest-transform, I don’t think that was even around at the time, so I did not have the chance to consider it. Might have to take it for a spin.

Hope it helps 🙏

[noahub]

Thanks for the quick reply @epavletic, much appreciated! Unfortunately this didn't solve the issue in my case -- I think there may be something in the next/jest base configuration that is causing a problem. I will have to do some more digging.

[robertgr991]

@noahub Did you manage to find a solution to make it work with Next.js?

[noahub]

@robertgr991 unfortunately I haven't had the time to revisit this yet. For the time being, my bandaid solution has been to change references to my theme variables to use optional chaining. Something like:

color: ${vars?.colors.links.default};

[robertgr991]

@noahub My trick is to resolve the jest config from next.js, than modify it to make it work with vanilla-extract and return it.

module.exports = async function jestConfigResolver() {
  // createJestConfig is exported this way to ensure that next/jest can load the Next.js config which is async
  const jestConfigResolver = createJestConfig(customJestConfig);
  const jestConfig = await jestConfigResolver();

  // Interferes with vanilla-extract
  const cssCodeFileMatcher = '^.+\\.(css|sass|scss)$';
  delete jestConfig['moduleNameMapper']?.[cssCodeFileMatcher];

  // Remove and append ts code transformer to give it less priority
  // than vanilla-extract transformer
  const tsCodeFileMatcher = '^.+\\.(js|jsx|ts|tsx|mjs)$';
  const tsCodeTransform = jestConfig['transform']?.[tsCodeFileMatcher];
  delete jestConfig['transform']?.[tsCodeFileMatcher];
  jestConfig['transform'][tsCodeFileMatcher] = tsCodeTransform;

  return jestConfig;
};

It's ugly, but so far, it's the only solution I found. Another one would have been to use babel-jest.