Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to specify import kind/name #12

Open
timdp opened this issue Oct 26, 2022 · 1 comment
Open

Ability to specify import kind/name #12

timdp opened this issue Oct 26, 2022 · 1 comment

Comments

@timdp
Copy link

timdp commented Oct 26, 2022

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?

@timdp
Copy link
Author

timdp commented Oct 31, 2022

I've implemented this in my own take on this plugin: https://www.npmjs.com/package/esbuild-plugin-import-pattern

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant