npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

vite-plugin-top-level-await-worker

v1.4.9

Published

Same as vite-plugin-top-level-await, but fixed for web workers.

Downloads

112

Readme

vite-plugin-top-level-await

Test Status npm Commitizen friendly code style: prettier License

Transform code to support top-level await in normal browsers for Vite. Support all modern browsers of Vite's default target without need to set build.target to esnext.

Installation

yarn add -D vite-plugin-top-level-await

Usage

Put this plugin in your plugin list. At most case you don't need to care the order, but if there're any plugin transforming bundle before it, there's a little chance that this plugin fails to parse code since it does only parse Rollup's output export { ... } export statement.

import topLevelAwait from "vite-plugin-top-level-await";

export default defineConfig({
  plugins: [
    topLevelAwait({
      // The export name of top-level await promise for each chunk module
      promiseExportName: "__tla",
      // The function to generate import names of top-level await promise in each chunk module
      promiseImportName: i => `__tla_${i}`
    })
  ]
});

Workers

You can use this plugin for workers (by putting it in config.worker.plugins).

  • If the worker format is ES, the plugin works normally.
  • If the worker format is IIFE, the plugin first let Vite build your worker as an ES bundle since IIFE doesn't support top-level awaits, and then build the transformed ES bundle to IIFE. Please use IIFE when targeting Firefox.
    const myWorker = import.meta.env.DEV
        // In development mode, `import`s in workers are not transformed, so you
        // must use `{ type: "module" }`.
      ? new Worker(new URL("./my-worker.js", import.meta.url), { type: "module" })
        // In build mode, let Vite and vite-plugin-top-level-await build a single-file
        // bundle of your worker that works on both modern browsers and Firefox.
      : new Worker(new URL("./my-worker.js", import.meta.url), { type: "classic" });

Note

This plugin transforms code from:

import { a } from "./a.js"; // This module uses top-level await
import { b } from "./b.js"; // This module uses top-level await too
import { c } from "./c.js"; // This module does NOT use top-level await

const x = 1;
await b.func();
const { y } = await somePromise;

export { x, y };

To:

import { a, __tla as __tla_0 } from "./a.js"; // This module uses top-level await
import { b, __tla as __tla_1 } from "./b.js"; // This module uses top-level await too
import { c } from "./c.js"; // This module does NOT use top-level await

// Original exported variables
let x, y;

// Await imported TLA promises and execute original top-level statements
let __tla = Promise.all([
  (() => { try { return __tla_0; } catch {} })(),
  (() => { try { return __tla_1; } catch {} })()
]).then(async () => {
  // Transform exported variables to assignments
  x = 1;

  await b.func();

  // Destructing patterns (and function / class declarations as well) are handled correctly
  ({ y } = await somePromise);
});

// Export top-level await promise
export { x, y, __tla };

It could handle correct usage of circular dependencies with the default behavior of ES standard. But when an TLA dependency is being awaited, an accessing to one of its exports will NOT raise an exception. At most time you don't need to care about this. These could be supported by doing more transformations of the whole AST but it will make building a lot slower. Open an issue and tell me your scenario if you really need the exception.