question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Alternative to 'import * as' module syntax

See original GitHub issue

This is no longer valid JavaScript:

import * as cosmiconfig from 'cosmiconfig';

cosmiconfig('module-name');

https://stackoverflow.com/questions/39415661/what-does-resolves-to-a-non-module-entity-and-cannot-be-imported-using-this/39415662#39415662

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:closed
  • Created 5 years ago
  • Comments:6 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
k2snowman69commented, Dec 16, 2018

Not to be a stickler but Typescript (from their documentation) highly recommends that you move over to using the esModuleInterop solution… From their documentation:

Note: The new behavior is added under a flag to avoid unwarranted breaks to existing code bases. We highly recommend applying it both to new and existing projects. For existing projects, namespace imports (import * as express from "express"; express();) will need to be converted to default imports (import express from "express"; express();)

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 with import).

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.

1reaction
davidtheclarkcommented, Dec 16, 2018

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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found