[Feature request] Allow import.meta.glob from node_modules

[IanVS]

Clear and concise description of the problem

I'm building a site that relies on some data that I would like to include via an npm install. These are markdown pages in a separate repo. Ideally, I'd be able to import.meta.glob('my-dependency/**/*.md') to access these files, but this is an invalid syntax. And trying /node_modules/my-dependency/**/*.md does not work either.

I guess this is probably because node_modules are specifically ignored, perhaps? 8b3d0ea

Suggested solution

I'm not sure how this would be accomplished, or whether it's even possible, honestly.

Alternative

My other option is to use git submodules to include my markdown files from the other repo, but I'd really rather not use submodules if I can help it.

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[maggie44]

Did you ever find a work around? I have run in to the same issue trying to import some language files from a node_module to use in a i18n language switcher.

[IanVS]

My work-around was to clone my other project into a sub-folder within my main project, which is ugly and a bit painful to manage, but is working.

[maggie44]

My work-around was to clone my other project into a sub-folder within my main project, which is ugly and a bit painful to manage, but is working.

Eek, I was worried that is what you might say. For me it is importing of language files so will become a pain for tracking changes on package updates, but haven't come up with anything better yet.

+1 for allowing import.meta.glob from node_modules

[hyrious]

Vite currently has a pre-bundling process that generally forbids anything that invoking a plugin to work, i.e. it requires all third-party libraries to be "production" code without being bound to some specific bundler.

An workaround is using symlinks to link some module in node_modules to somewhere out of it, in which case vite will treat that module as user code so it won't optimize it.

[maggie44]

Interesting approach, thanks for the input. Of course not ideal, but will give it some thought.

I can provide an example here of use case. I came across the issue because I am using Quasar, which provides a bunch of components out of the box for developing Vue sites. Some of these components include things like tables, menu items and so forth. These stock components have labels on them which are standard for all users, such as pagination on tables which have default next and previous labels. Rather than each user having all these components translated themselves, Quasar has language packs for these items in a whole bunch of languages already. The goal is to import those language packs from the Quasar node_module and in to the production build. Here is how it worked with Webpack:

https://quasar.dev/options/quasar-language-packs#dynamical-non-ssr-

[bluwy]

I think this feature is supported since #6056. /node_modules/my-dependency/**/*.md should work now. @IanVS can you help verify this? Otherwise https://github.com/antfu/vite-plugin-glob could also be an alternative.

[maggie44]

Following this: https://vitejs.dev/guide/features.html#glob-import

      const modules = import.meta.glob('../../node_modules/quasar/lang/*.js')

      console.log(modules)

      for (const path in modules) {
        await modules[path]().then((mod) => {
          console.log(path, mod)
        })
      }

Produces this:

Object { "../../node_modules/quasar/lang/ar.js": js(), "../../node_modules/quasar/lang/az-Latn.js": js(), "../../node_modules/quasar/lang/bg.js": js(), "../../node_modules/quasar/lang/bn.js": js(), "../../node_modules/quasar/lang/ca.js": js(), "../../node_modules/quasar/lang/cs.js": js(), "../../node_modules/quasar/lang/da.js": js(), "../../node_modules/quasar/lang/de.js": js(), "../../node_modules/quasar/lang/el.js": js(), "../../node_modules/quasar/lang/en-GB.js": js(), … }
MainLayout.vue:155:14

...

Uncaught (in promise) ReferenceError: module is not defined
    <anonymous> http://localhost:9000/node_modules/quasar/lang/ar.js?t=1648629007295:6

[hyrious]

I guess that's because using import() on commonjs modules (which has top level module.exports = xxx) does not work in the browser.

Maybe the vite server could add a quick test about if the served file is in commonjs, run esbuild.transform() to turn it to esm.

[maggie44]

A working example using the glob pattern provided here: quasarframework/quasar#12911 (comment)

Seems like it is allowing the imports from node_modules, must have been something I was doing wrong with my example. Looks like it is that I was importing the .js files instead of .mjs, so as mentioned above importing from commonjs modules (module.exports = {).

[kenkunz]

FYI, this is working for me in a SvelteKit app. I was able to use import.meta.glob to import an optional npm dependency (as a work-around for #6007). See this comment and following.

[bluwy]

Closing as this is reported to be working. Thanks y'all who helped verify this!

Re #5728 (comment), @Maggie0002 if you're importing files that aren't esm from the node_modules, you need to explicitly optimize them by placing the individual files in optimizeDeps.include. Unfortunately, optimizeDeps.include doesn't support globs, but there's #5419 to track it.

Maybe the vite server could add a quick test about if the served file is in commonjs, run esbuild.transform() to turn it to esm.

@hyrious Vite's philosophy around dealing with CJS is that they should be prebundled first before the source code interacts with it, so it's unlikely that we would transpile with esbuild on-the-fly. Using optimizeDeps.include should be the way to go for now.