How to test Solidjs code?

[jorroll]

It would be great to have a doc dedicated to testing code with solid. By searching the other discussion items, I learned of the solid-testing-library which is a great resource. But the solid-testing-library appears to be for testing Solid components. What about unit testing a function that, e.g., uses an onMount hook?

Looking through the source code for help, I found this bit inside the signals test file:

test("Create an Effect", () => {
  let temp: string;
  createRoot(() => {
    onMount(() => (temp = "unpure"));
  });
  expect(temp!).toBe("unpure");
});

Unfortunately, recreating this simple test in my own project doesn't work (the onMount callback is never called). It's unclear if i'm missing some setup code that's related to Solidjs or if something else unrelated to solid is going wrong.

[ryansolid]

Are you using solid-jest. It's possible that since you aren't using JSX it isn't obvious the server version of Solid is getting pulled in that doesn't run onMount calls.

https://github.com/solidui/solid-jest

[jorroll]

Thanks! I wasn't aware of solid-jest and I'm not currently using it. Am I correct in thinking that, because I'm not testing code containing JSX, I shouldn't need to use solid-jest?

At the moment, I'm just attempting to run the following test using ts-jest (no other files are imported by the test):

import { createRoot, onMount } from 'solid-js';

describe('test', () => {
  it('works', () => {
    let temp: string;
    createRoot(() => {
      onMount(() => (temp = 'unpure'));
    });
    expect(temp!).toBe('unpure');
  });
});

The documentation introduces using Solidjs without compilation with the context of ~ "Solidjs without JSX". The implication I drew (perhaps mistakenly) is that the compilation is necessary because of the JSX code.

[jorroll]

Even though this test doesn't import anything else, it is being run in a repo that contains other typescript code. For various reasons it wasn't super easy to switch to using solid-jest/preset/browser just for this small test, but I've now done so and I see the test is now passing.

To better understand what's going on, is there a way that I could re-write this test so that it doesn't require compilation? Thanks so much for you time! It doesn't appear that this question is addressed in the current documentation but my apologies if it is and I've just missed it.

[ryansolid]

Yeah haven't missed it. I just wasn't expecting the non-JSX use and this only stopped working a couple versions ago. Basically the conflict is I have 2 versions of everything in Solid a browser and server version. In the browser Solid does stuff you'd expect, on the server we turn into a dumb templating language like PUG more or less. All reactivity is removed. While it's true JSX compilation differs, I actually swap the Runtimes to remove the unnecessary overhead.

However I wanted it all to use the same import statements so the that code was Isomorphic. Ie.. you could write it once with all the same imports and it would work in either environment. While I could look at doing aliasing in the SSR build process this didn't lend with things which might not be bundled on the server. As it turns out Node has a mechanism for this with their ESM support called Conditional Exports. This works great. And bundler's even support it.

However Legacy stuff like Jest doesn't respect it. And as it turns out Vite server resolution is also legacy. So I basically had to make a choice on what the "main" export field was, client or server. I had had it as the client build but that wouldn't work with Vite. The proper way Legacy systems had been doing SSR was the "browser" field which is recognized by most tools. Well most tools except Jest. So I made "main" server version and made "browser" point to the client versions. Then I wrote the plugin so that Jest would look in the browser field.

Technically speaking you could probably be explicit with your import. Importing from "solid-js/dist/solid.cjs" or "solid-js/dist/solid.js" depending of CJS or ESM. But I suspect TS might have an issue with that because the types are located at the root of the project. Since you aren't using SolidJS web this should be fine since you don't have to worry about the packages referencing each other.

[jorroll]

Thanks! That makes sense and I appreciate the dilemma. I don't have time to test at the moment, but another workaround for Jest might be using the moduleNameMapper field (i.e. Jest's version of Typescript's "paths") to redirect the "solid-js" imports in jest to the proper build. I don't think that the moduleNameMapper field affects Typescript, even for ts-jest, so this might bypass potential types issues.

[jorroll]

@ryansolid actually I realized it would be really easy to test moduleNameMapper and I see it works as desired. For example in my monorepo:

moduleNameMapper: {
  "solid-js": "<rootDir>/../../node_modules/solid-js/dist/solid.cjs",
},

[jorroll]

Posting this here in case someone else finds it useful. If you need to test Solidjs code using the typescript compiler (rather than the babel-typescript compiler), ts-jest supports postprocessing using babel.

As a rough example:

// jest.config.js
{
  globals: {
    "ts-jest": {
      tsConfig: "tsconfig.spec.json",
      babelConfig: {
        presets: ["babel-preset-solid", "@babel/preset-env"],
      },
    },
  },
  moduleNameMapper: {
    "solid-js": "<rootDir>/../../node_modules/solid-js/dist/solid.cjs",
  },
}

In the example we configure ts-jest by specifying the location of the tsconfig.json file for the tests, we provide a babel config, and we use the moduleNameMapper option to force solid-js to use the browser build (see this comment, above, for why this is necessary).