import_meta.glob is not a function (updating vite@2.3.4 -> vite@2.3.5)

[brillout]

The latest release 2.3.5 breaks vite-plugin-ssr and the browser throws Uncaught TypeError: import_meta.glob is not a function.

I'm looking at what change may have led to that.

[brillout]

I'm guessing this is related to the breaking change evanw/esbuild#660 introduced in esbuild@0.12.0. Updating from vite@2.3.4 to vite@2.3.5 also updates esbuild@^0.11.23 to esbuild@^0.12.5.

[Shinigami92]

So it's a down-/up-stream bug 😅
Could you open an issue there and link it here? This will help for tracking 🙂

[brillout]

So it's a down-/up-stream bug 😅

😀

Could you open an issue there and link it here? This will help for tracking 🙂

I'm not sure if it's an esbuild bug, since it's an expected breaking change. I'll try to find some time this week to dig more what's going on.

[ygj6]

@brillout it looks like a spelling error，make sure you are not using import.meta.glob

If not, it is better to give a reproduction

[brillout]

@ygj6 It's not a spelling error.

Reproduction

yarn create vite-plugin-ssr
cd vite-ssr-project/
yarn
yarn dev

Go to localhost:3000 and click on the counter => page is interactive. (You have vite@2.3.4 installed.)

yarn install vite@2.3.5

Click on the counter => it doesn't work and the browser throws the aforementioned error.

[haoqunjiang]

Not a bug. Not introduced by that PR.

[haoqunjiang]

The issue happens in esbuild >= 0.12.4.
But it's not a bug.

The problem here is that you shouldn't transpile the client files to CommonJS. import.meta is not available in the CommonJS environment, so esbuild automatically injects a shim and transformed it for you (var import_meta = {}; import_meta.glob(...))

[brillout]

The client is not transpiled to CommonJS. If you look at node_modules/.vite/vite-plugin-ssr_client.js (after running the reproduction steps) you'll see ES Modules, as expected.

By a matter of fact this is a bug and regression, since everything works with vite@2.3.4. Not sure if it only affects vite-plugin-ssr but import.meta.glob is not being processed as it should.

[haoqunjiang]

Sorry for misreading the file path.

Here's the workaround:
Create a tsconfig.json in the page-files folder, with the following content:

{
  "compilerOptions": {
    "target": "ESNext"
  }
}

[haoqunjiang]

Caused by this evanw/esbuild#277

[haoqunjiang]

Vite may help work around this issue by overwriting the TypeScript target when invoking esbuild.

But I'm not sure if it is the right thing to do.

Sure overwriting the TypeScript target does no harm and is very likely to be backward-compatible in Vite.
But the new esbuild behavior makes sense too.
For now it's the target option that makes the difference, but maybe in the future there will be more options taken into consideration. We can't keep overwriting all these options.

Shipping TypeScript source files in an npm package may not be a good practice IMO.

[haoqunjiang]

On why shipping pure TS packages (or to say, exposing pure TS files for users to import) is a bad idea:

• In the general sense, see discussions at Guidance on shipping ts within node_modules microsoft/TypeScript#12358
• On practical issues, all these configuration fields in tsconfig.json may affect the output of TS compilation https://esbuild.github.io/content-types/#tsconfig-json you can't expect the users' configurations are always the same as yours.

[brillout]

I changed vite-plugin-ssr to now publish ESM instead of TS.

Still no luck; the same error is thrown in the browser.

The file vite-ssr-project/node_modules/vite-plugin-ssr/dist/esm/page-files/pageFiles.client.js is now ESM.

// Vite resolves globs with micromatch: https://github.com/micromatch/micromatch
// Pattern `*([a-zA-Z0-9])` is an Extglob: https://github.com/micromatch/micromatch#extglobs
export const pageFiles = {
    //@ts-ignore
    '.page': import.meta.glob('/**/*.page.*([a-zA-Z0-9])'),
    //@ts-ignore
    '.page.client': import.meta.glob('/**/*.page.client.*([a-zA-Z0-9])'),
    //@ts-ignore
    '.page.route': import.meta.glob('/**/*.page.route.*([a-zA-Z0-9])')
};
//# sourceMappingURL=pageFiles.client.js.map

But Vite still transforms it to import_meta.glob in vite-ssr-project/node_modules/.vite/vite-plugin-ssr_client.js.

// node_modules/vite-plugin-ssr/dist/esm/page-files/pageFiles.client.js
var import_meta = {};
var pageFiles = {
  ".page": import_meta.glob("/**/*.page.*([a-zA-Z0-9])"),
  ".page.client": import_meta.glob("/**/*.page.client.*([a-zA-Z0-9])"),
  ".page.route": import_meta.glob("/**/*.page.route.*([a-zA-Z0-9])")
};

Same reproduction steps as above. (Use yarn create vite-plugin-ssr and not npm init vite-plugin-ssr because yarn always get's the latest version of create-vite-plugin-ssr, unlike npm which uses a cache.)

So it does seem like a Vite bug.

(Btw thanks for your suggestion to not publish TypeScript code; it makes a lot of sense and I'm glad to now pbulish ESM instead.)

[haoqunjiang]

🤔 It's still the tsconfig.json issue. esbuild uses its target to transpile .js files too.
I think I need to file an issue to esbuild. This will cause much confusion.

As a workaround, you can add tsconfig.json to .npmignore to avoid it being published on npm; or better, use the files field in package.json to only publish the necessary files.

[brillout]

You are right, changing the tsconfig.json solved it.

Yea it's quite unexpected to have esbuild read tsconfig.json even though I don't publish any TS anymore. It would have taken me a lot of time to figure out if you didn't help.

Thank you for your helpful answers, I appreciate it.

I guess we can close this ticket since it's more a esbuild bug / DX problem.

[github-actions]

This issue has been locked since it has been closed for more than 14 days.

If you have found a concrete bug or regression related to it, please open a new bug report with a reproduction against the latest Vite version. If you have any other comments you should join the chat at Vite Land or create a new discussion.