prefer-default-export doesn't understand destructoring

[scottnonnenberg]

The prefer-default-export rule fires when I do this:

// typography.js
export const { rhythm, TypographyStyle } = typography;

But I get import-named complaining that 'rhythm' cannot be found when I change it back to:

// typography.js
export default typography;

And continue to reference it like this:

// component.js
import { rhythm } from 'utils/typography';

I guess I prefer the first option, but that would require that prefer-default-export understand destructuring.

On the other hand, do we really want to be that restrictive on the import destructuring check? Isn't it reasonable to destructure a default export?

[benmosher]

The prefer-default-export issue is a bug.

The named rule behavior is correct, though. The default export is just a named export that is named "default" and has special syntax. You may be able to do that with Babel 5 because of the way it encodes a single default export into CommonJS, but it's technically invalid. Named exports must be explicitly declared, as in your destructuring example.

Will make note of this and address in prefer-default-export. Thanks!

[scottnonnenberg]

Good to know about the correct syntax. I am using Babel 6 however, so it continues to allow the incorrect usage even in the current release.

By the way, many thanks for this package! It's so useful to know that your imports are correct before running the code. And I thought I was the only one that wanted my imports sorted like that! :0)

[gavriguy]

Just saw this issue - I'll create a PR to fix it.
BTW If you have any issue regarding prefer-default-export I'll be happy try and fix it - please mention me in the issue if you can so I can respond more quickly.

[sk1e]

@benmosher @gavriguy Hi, there is also destructuring syntax for arrays:

export const [one, two] = [1, 2];

and for nested things:

export const [one, { two, three: [three] }] = [1, { two: 2, three: [3] }];

Plugin still complaining about prefer-default-export for these cases.

[ljharb]

Shouldn't it? Those are named exports, and prefer-default-export wants a default export.

[sk1e]

I guess it shouldn't since there are multiple exports and rule states about "When there is only a single export from a module, prefer using default export over named export."

[ljharb]

gotcha. can you file a new issue for that?

[sk1e]

ok