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.

No default export (1.8.4)

See original GitHub issue

With v1.8.4 I got the following error:

import dayjs from 'dayjs';

Module ‘“…/node_modules/dayjs/index”’ has no default export.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:2
  • Comments:22 (11 by maintainers)

github_iconTop GitHub Comments

5reactions
roblevintenniscommented, Sep 5, 2019

Yes, I’m getting this. I don’t have time to setup a toy repo and everything, but will post some screenshots of what I’m seeing:

Using:

import * as dayjs_ from 'dayjs';
console.log('daysjs before: ', dayjs)
debugger;
const dayjs = (dayjs_).default || dayjs_;
console.log('daysjs after: ', dayjs)
debugger;

I see it’s undefined until I apply the .default workaround others have mentioned:

image

The logs in ^ should show that just doing import * as dayjs_ from 'dayjs'; in webpack results in undefined—looks like it’s considering it a default export.

But even when I attempt to use es6 import default approach (e.g. import dayjsAsDefault from 'dayjs';), it doesn’t get fully resolved. This is after such import:

image

and dayjsAsDefault is undefined

Personally, I’d reopen this until it’s proven to work with Webpack given the popularity of that bundler but up to maintainer of course 😉 For now, we’ll all have imports with comments pointing to this issue

3reactions
neemzycommented, Feb 15, 2019

IMO this shouldn’t be closed. Pre-1.8.4 behaviour (import dayjs from "dayjs";) is still broken and this is a BC break. We are using dayjs in several in-house apps and packages which depend on each other, and this has just broken our entire stack with a single dependency update. We would really appreciate not having to spend a whole day editing our import code / editing package.json to use a fixed 1.8.3 version on every single app/package.

Would you please consider going the extra mile to try and make import and require behaviours both work as intended? I can try to help if you give me a few pointers about the specific problem. Thanks a ton!

Read more comments on GitHub >

github_iconTop Results From Across the Web

VS Code tips — Convert default export to named ... - YouTube
Today's VS Code refactoring: convert default export to named exportSafely convert between default exports and named exports in JavaScript ...
Read more >
error TS1192: Module '" A.module"' has no default export
This was a simple error. It occurred due to the missing {} around the module name in the import statement itself.
Read more >
Documentation - Modules - TypeScript
Each module can optionally export a default export. Default exports are marked with the keyword default ; and there can only be one...
Read more >
Overview of Oracle Data Pump
For privileged users, a default directory object is available. ... 1.8.4 Using Substitution Variables with Oracle Data Pump Exports.
Read more >
TLS_MGM module - openSIPS
It also exports pseudo variables with certificate and TLS parameters. ... 1.8.4. private_key ([domain](string) ... No default value. Example 1.15.
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