Auto-resolve named exports from ES2015 modules
See original GitHub issueIt is a common pattern to have a module that exports multiple things, and possibly no default thing. Example:
export function foo() {
...
}
export function bar() {
...
}
Now, if I want to use one of these functions, I am left in the dust by import-js. It would be nice if we could resolve these named exports automatically.
Issue Analytics
- State:
- Created 8 years ago
- Reactions:5
- Comments:22
Top Results From Across the Web
ES Modules: Using Named Exports as the Default Export
You can assign a new name to a named export as you import it, allowing you to resolve naming collisions, or give the...
Read more >Issue with backend-side ES6 imports with "type":"module" with ...
My package.json has the line "type": "module" , which enables ES6 module ... "type":"module" #23029 Export defaults as named exports #23341 ...
Read more >Refactor/move file utilities with Meteor 1.3 Imports - Meteor forums
They have an applicable issue, Auto-resolve named exports from ES2015 modules. Looking at it, parsing all files to find the exports every time...
Read more >Module.exports | npm.io
Export all named exports again, as module.default, unless a default is defined. babel-pluginmodule.exports. 0.0.4 • Published 6 years ago ...
Read more >How to export named imports from an ES2015 module with Flow
I'm basically creating an index.js file in a folder with components to bundle them for easy imports elsewhere. Using Flow you will get...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This will be fixed as soon as #365 is merged.
This is related to #184 and #183. I’ve been thinking about this and I think we could add a cache of some sort to the file system.
.import-js.cache.json
or something. Depending on how long it takes for this cache file to generate, we can either add an explicit command (e.g.import-js init
) or make it a one-time startup thing. And if we’re smart about what we store in this cache, we can probably use a little bit of time on some import calls to check if we need to update the cache.I have a hard time seeing a solution that doesn’t use a cache.
When you say “it is common”, how common do you mean? I haven’t come across many projects that do that.