Menci / vite-plugin-top-level-await

Transform code to support top-level await in normal browsers for Vite.
MIT License
273 stars 15 forks source link

Can't seem to get Vite to accept top level await in a npm package #13

Closed Tokimon closed 2 years ago

Tokimon commented 2 years ago

I am trying to build a small project, with TypeScript and SolidJS, where I use a npm package (kissfft-wasm) that uses a top level await in one of their files. But it just keeps failing with this message:

image

I am not sure if the package is doing something wrong or my config is just not setup up correctly to use top level awaits.

Hopefully some of you bright people might know how to fix this.

My current vite.config.ts

I have tried a couple of things so this is the setup I was hoping would make it work, but doesn't.

import { defineConfig } from 'vite';
import solidPlugin from 'vite-plugin-solid';
import wasm from "vite-plugin-wasm";
import topLevelAwait from "vite-plugin-top-level-await";

export default defineConfig({
  plugins: [
    wasm(),
    topLevelAwait(),
    solidPlugin(),
  ],
  server: {
    port: 3333,
  },
  build: {
    target: "esnext",
    commonjsOptions: { // <- I don't know this make sense at all to include when target is "esnext"
      include: [/node_modules\/kissfft-wasm\/lib\/wasm\.js/]
    }
  }
});

I did try to add optimizeDeps.include but that didn't do much either

optimizeDeps: {
  include: ['kissfft-wasm']
}
Menci commented 2 years ago

It's optimizeDeps.exclude, not include

Tokimon commented 2 years ago

hm.. So you exclude it from the optimizations? I guess that is one way of doing it. But it seems to work. Thank you.

Menci commented 2 years ago

Yes, what Vite's optimizeDeps does is pre-build you NPM packages with esbuild and generate optimized bundle for them, to reduce the pressure of Rollup's HMR during preview build.

However, the esbuild arguments for optimizeDeps and production build (in production build there's also a esbuild step) are separated. This plugin overwrites the production esbuild's argument to stop esbuild from complaining the target doesn't support TLA (and finally, after processing TLAs, this plugin transform the code back to the orignal target with esbuild again).

I will consider also overwrite the esbuild argument for optimizeDeps, I guess that will solve this issue. But notice that if you'are using vite-plugin-wasm you'll always need to exclude the package containing WASM imports to avoid some issues (https://github.com/Menci/vite-plugin-wasm/pull/11).

Tokimon commented 2 years ago

Well it doesn't seem to matter if I use the vite-plugin-wasm or vite-plugin-top-level-await plugins. With or without I need to exclude it. But then the package fails in the next step which is the kissfft.cjs. I am not entirely sure why as it should return the .default() (or at least just a function) correctly enough. I only assume that that file should have been included in the build as well to be treated correctly. I looked at their repository and they use vitest for their testing, which I assume works since it has been released. So it is a bit strange, but it seems like am at a dead end with this one...

Menci commented 2 years ago

Unfortunately I believe that is not related to my plugin -- since I don't do anything with the preview build.

Menci commented 2 years ago

The original issue (error messages caused by optimizeDeps) has been fixed in v1.2.1. Your cjs import problem is not related.

Tokimon commented 2 years ago

Yes the first part of the problem was to exclude the library (optimizeDeps.exclude). The second was to enable CommonJS imports (@originjs/vite-plugin-commonjs). So all good now. Thank you for all your help.