Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for vitest testing framework #88

Open
4 tasks done
ldover opened this issue Jan 18, 2023 · 10 comments
Open
4 tasks done

Add support for vitest testing framework #88

ldover opened this issue Jan 18, 2023 · 10 comments
Labels
enhancement New feature or request

Comments

@ldover
Copy link

ldover commented Jan 18, 2023

Clear and concise description of the problem

This tool abstracts Electron and Vite configuration beautifully; if it could do the same for a testing framework that would be dream, saving devs some manual work.

Suggested solution

At project creation time add the option to add a testing framework, maybe vitest (https://vitest.dev/).

Alternative

No response

Additional context

I've managed to set up vitest, but with my limited coverage of electron-vite, it was imperfect integration. Struggled with nested renderer folder and ended up adding another index.html file in the project root in order to make all the paths / modules resolve correctly.

Additionally had to add type: module in package.json for vite to work.

Validations

@ldover ldover added the enhancement New feature or request label Jan 18, 2023
@alex8088
Copy link
Owner

Testing with vitest is awesome. But vitest only supports Vite's configuration. This is where the difficulty lies. I'm also trying to optimize this so that developers can test more easily. Maybe the scaffolding will join the unit testing framework after solving this problem.

You can add a Vite configuration file in root, use the same configuration as renderer(in electron.vite.config.*), and specify the entry point.

/// <reference types="vitest" />
import { defineConfig } from "vite";
import { resolve } from 'path';

export default defineConfig({
  test: {
    // ...
  },
  build: {
    rollupOptions: {
      input: {
        index: resolve(__dirname, 'src/renderer/index.html')
      }
    }
  }
});

This is a temporary solution, which does not meet the original design intention of electron-vite.

In addition, Electron not supports type: module

@nanxfu
Copy link

nanxfu commented Feb 20, 2023

Testing with is awesome. But only supports Vite's configuration. This is where the difficulty lies. I'm also trying to optimize this so that developers can test more easily. Maybe the scaffolding will join the unit testing framework after solving this problem.vitest``vitest

You can add a Vite configuration file in root, use the same configuration as renderer(in ), and specify the entry point.electron.vite.config.*

/// <reference types="vitest" />
import { defineConfig } from "vite";
import { resolve } from 'path';

export default defineConfig({
  test: {
    // ...
  },
  build: {
    rollupOptions: {
      input: {
        index: resolve(__dirname, 'src/renderer/index.html')
      }
    }
  }
});

This is a temporary solution, which does not meet the original design intention of .electron-vite

In addition, Electron not supports type: module

Sorry to borther you. But I just don't understand how to specify the entry point.electron.vite.config.*. Won't you set the input.index:resolve(__dirname, 'src/renderer/index.html') in Vite configuration file in the root? where is the place to specify the entry point?

@Y2zz
Copy link

Y2zz commented Mar 8, 2023

Support for vitest is still very important

@GuillaumeQuenneville
Copy link

GuillaumeQuenneville commented Mar 27, 2023

electron/electron#37535

There's a PR open to support esm modules that seems like it will probably be merged.

If I understand all of this correctly, if electron vite gets updated to point at whatever version includes this change, we can get rid of the commonjs transpiling steps and we'll get vitest support for free?

@annymosse
Copy link

You can add a Vite configuration file in root, use the same configuration as renderer(in electron.vite.config.*), and specify the entry point.

/// <reference types="vitest" />
import { defineConfig } from "vite";
import { resolve } from 'path';

export default defineConfig({
  test: {
    // ...
  },
  build: {
    rollupOptions: {
      input: {
        index: resolve(__dirname, 'src/renderer/index.html')
      }
    }
  }
});

this doesn't make vite load the electron.vite.config file configs, it just load the entry point of the index.html file without the plugins loaded inside the electron.vite.config.{ts,js,*}, I can guess that we can load the plugins inside vite.config.ts and export these plugins to electron.vite.config file , am I missing something in here ? (I'm just started experimenting this lib for few times only ).

@paltry-pleuroma
Copy link

I made a serious attempt at porting a project from a CRA app but despite many permutations, I was not able to get testing set up. It's hard to understand how this project could be useful in production without robust testing support and I wonder if this is in violation of semver given the lack of prerelease in version. I looked at using vite-jest but it doesn't support mocking modules.

I tried using both the renderer property of the return value of electron-vite's defineConfig AND the renderer value passed to the defineConfig in both a vite.config.js and a vitest.config.js file while also experimenting with the test property in such a way. I also experimented with using the mergeConfig.

@SiriffoS
Copy link

I am also trying to migrate a project to electron-vite. Whats a good test framework that works well with electron-vite?

@SvetBorislavov
Copy link

Path aliases do not work with vitest

@gxy5202
Copy link

gxy5202 commented May 8, 2024

I have the same problem... Do we have some new solutions?

@Repugraf
Copy link

Any help required with this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests