Alternative to 'import * as' module syntax
See original GitHub issueThis is no longer valid JavaScript:
import * as cosmiconfig from 'cosmiconfig';
cosmiconfig('module-name');
An ES6 module namespace object cannot be invoked as a function or with new. The thing you import using * as X from a module is defined to only have properties.
As a backwards-compatible change, this module should have something like this added at the bottom of src/index.js
:
cosmiconfig.cosmiconfig = cosmiconfig;
That way we’ll be able to do this:
import { cosmiconfig } from 'cosmiconfig';
cosmiconfig('module-name');
It’s a bit silly. A default
export is doable too, but as an external TypeScript user, I find it inconvenient to have a separate import syntax and/or group for importing this one function verses any associated types the type definitions also export.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
CommonJS vs. ES Modules: Modules and Imports in NodeJS
Instead of the require() function for importing modules, we now use a specific import syntax. Also, instead of a specific module object, we...
Read more >JavaScript modules - MDN Web Docs
This guide gives you all you need to get started with JavaScript module syntax.
Read more >JavaScript require vs import - Flexiple
Syntax, explanation, example and differences between JavaScript require and import statements and other related concepts.
Read more >Syntax alternatives for modules - open-std.org
Ideally, we keep “module” and. “import” as keywords, but if that is not feasible given existing code bases, we have alternatives. This.
Read more >The JavaScript Modules Handbook – Complete Guide to ES ...
An alternative to the import specifier's dot ( . ) syntax is to write out the entire relative path to a module's location....
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 FreeTop 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
Top GitHub Comments
Not to be a stickler but Typescript (from their documentation) highly recommends that you move over to using the esModuleInterop solution… From their documentation:
The reason for this is the old
import * as
syntax does go against the tc39 spec.I don’t disagree that this won’t make typescript user’s lives easier in the short term but if added, in the long term you’ll likely just end up reverting the PR in the future anyways.
I’d say the better solution for your project is to upgrade to using the esModuleInterop (I just did this across my codebases, its a simple search and replace of
import * as
withimport
).Merging the PR doesn’t impact me at all, more just wanted to let you know that long term the
import * as
syntax will likely be deprecated and removed in future versions of typescript so if you’re writing new code with it, probably want to just fix it now.You’re right, @JoshuaKGoldberg, that this is ES module syntax; but the aversion to a default export seems specific to TypeScript? I think a default export is fine and standard, so I’m not sure why it would become an issue for people using ES modules. I’d rather not make API changes to accommodate preferences like this, as long as the current API does work fine.