Extract entrypoint options improvements

[aklinker1]

This is an issue for addressing several issues with how entrypoints are imported to get their options.

• Allow using imported variables in entrypoint options #336
• Vite plugins (e.g. Babel) not executed for entrypoints #504
• Errors Thrown When Two Nested Modules Import the Same Module #634
• import.meta.glob doesn't work #635
• Exclude Zod #824

Edit: As of v0.19.0-alpha1, all the above issues work with:

export default defineConfig({
  experimental: {
    entrypointImporter: "vite-node",
  },
});

Will add to this list if other issues come up.

[aklinker1]

Alright, I have a proof of concept using Vite's runtime API to load entrypoints: #585

• Supports custom transformations via vite plugins
• Lets you import variables or use import.meta.glob

So this should cover all the issues people have reported.

HOWEVER... it appears the vite runtime can't import CSS modules, which is kinda important. I've asked a question about it in the vite discord, so we'll se if I get a useful response. https://discord.com/channels/804011606160703521/1236142702785990677/1236142702785990677

[aklinker1]

Alright, it was an issue on my side. Just needed to start the vite server lol. So it's working now.

I need to clean up my changes before opening a real PR. Probably won't get to it this weekend... we'll see. But I got everything working :)

[aklinker1]

Last problem to address... Module side effects.

Say you're using storage item in your content script:

// utils/storage.ts
export const isXyzEnabled = storage.defineItem(...);

// entrypoints/content.ts
import { isXyzEnabled } from '~/utils/storage';

export default defineContentScript({
  // ...
  async main() {
    console.log(await isXyzEnabled.getValue());
  }
});

In this example, storage.defineItem actually includes side effects, like checking if the storage item needs migrated. Should a side effect like this run? I don't think so, and I can't think of reason a side effect like this should ever run. That is, unless it's related to an imported variable used in the options.

So I have a decision to make. When importing entrypoints during the build to get their config, do I...

1. delete the main function and remove unused imports to prevent side-effects from running? or
2. Leave everything as is and let all side-effects run

I think... I'm gonna go with option 1, and remove the main function. For performance reasons (importing less code as project grows) as well as avoiding weird edge cases around the node environment these files are loaded into (similar to what I'm currently doing with jiti).

So I have to decide the best way to do that. Removing the main function should be simple... Use magicast or regex. To remove unused imports after that... I'm not sure how to do that. Regex again? Or use magicast to get the imports, and find/replace if they're used. Probably that. I'll just use magicast for everything if possible.

[aklinker1]

Playing around a bit, removing unused imports isn't a simple task lol. Instead, I'm just going to remove main function via magicast, then let vite tree-shake out the modules? Not sure how the runtime API handles this... Might need to come back in the future and remove imports properly.

[aklinker1]

Released v0.18.0 with an experimental flag to enable this feature. If you use PNPM, for some reason it requires setting shamefully-hoist=true... And there are a couple of other problems when ran outside this monorepo... So this isn't quite ready for use yet.

[rxliuli]

I don't understand why there are no obvious side effects after importing, and it doesn't work. For example, extracting the configuration file to config.json and then using it doesn't work.

config.json

{
  "list": [
    { "name": "John", "age": 30 },
    { "name": "Jane", "age": 25 },
    { "name": "Jim", "age": 40 }
  ]
}

background.ts

import { defineBackground } from '~/sandbox';
import config from './config.json';

const list = config.list;

export default defineBackground({
  main() {
    console.log(list);
  },
});