Right now, imports are hardcoded as import * from './x', which generates a lot of boilerplate if there's only one export.

Particularly if you only have a default export, you get something like:

var __exports = {};
__export(__exports, {
  default: () => __default
});
var __default = 'export goes here';

while it could just be:

var x = 'export goes here';

which is the behavior you get with import x from './x'.

Additionally, I'm using this in conjunction with esbuild-plugin-yaml, which generates even more overhead because every "export" essentially gets repeated. While this is not a common case, it does illustrate the problem rather well.

You could argue that esbuild should figure this out, but I think the plugin can also do a better job at understanding exports, be it with some help from the programmer.

One option would be to embed some config in the import glob:

import justTheDefaultExports from './stuff/*.js#default'
import foosAndBars from './named/*.js#foo,bar'

or the config could be prefixed instead of suffixed. Alternatively, this could be a good case for (nonstandard) import assertions, but I imagine that would take more parsing.

Just spitballing though. WDYT?

I have a scenario where a glob string (e.g. ./processor/**/*) is used in multiple places in files that are in different directories.
In these directories, the resolution of the globbing must result in different files. However, during processing, the globbing is done only once, and when the same glob string appears in a another file, then the same files are used again.

I provided an example in this Github repository:
https://github.com/MartinKolbAtWork/esbuild-plugin-import-glob-issue

The files in ProcessorManagerA.js and ProcessorManagerB.js both use the same glob string ./processor/**/*
The esbuild process can be started using npm run build.
The globbing from ProcessorManagerA.js should result in using the files Processor1 and Processor2.
The globbing from ProcessorManagerB.js should result in using the files Processor3, Processor4, and Processor5.

However, when looking into the output file out.js, it can be seen that only Processor1 and Processor2 were found and processed.

A pull-request that proposes a possible solution can be found here: #10

Have you had any issues using this with TS? I'm getting

 > import-glob:./**/*:2:305: error: Could not resolve "startAPI.ts" (mark it as external to exclude it from the bundle)
    2 │ ...s.ts';import * as module6 from 'startAPI.ts'
      ╵                                   ~~~~~~~~~~~~~

When trying to use for the first time. I can provide a better reproduction if you'd like, on ESBuild 0.11.12

It's great that this plugin exposes both the modules and their filenames. However, it's somewhat tedious that it does so by exposing a named export alongside a default one. Additionally, I think one should have to zip the two arrays to match a module to its filename.

Personally, I would export an array of module records: { filename: string, module: any }[]. To help folks who aren't interested in the filenames, you could optionally also export the modules, and the same logic could be applied to the filenames.

Because this would create multiple exports, and also because a lot of people feel that default exports shouldn't be part of JS, all three exports should be named. I.e., you could import { records } (I can't think of a better name right now), but also { modules, filenames } to get the current behavior.

Sidenote: I've noticed that bundlers typically refer to the filenames with id, because they're internally treated as module identifiers. Thus, this could be an opportunity to move away from "filename" too.

Hey there! Thanks a lot for this plugin!

I am trying to use it with an import syntax like that :

import ImportGlobPlugin from 'esbuild-plugin-import-glob';
await esbuild.build( {
	entryPoints: [ './main.js' ],
	bundle: true,
	outfile: './scripts.js',
	plugins: [
		ImportGlobPlugin(),
	],
} );

But I get this error:
TypeError: ImportGlobPlugin is not a function

Is there anything I can do?

Thank you very much for your help!

fast-glob removed relative file symbol ./, so it report this error message:

When I change fast-glob to glob, it works.

rails/jsbundling-rails@main...xiaohui-zhangxh:main