Rule proposal: no-wildcard-import

[silvenon]

Found this rule in Airbnb's JS styleguide and I liked it.

[eslintbot]

@silvenon Thanks for the issue! If you're reporting a bug, please be sure to include:

1. The version of ESLint you are using (run eslint -v)
2. What you did (the source code and ESLint configuration)
3. The actual ESLint output complete with numbers
4. What you expected to happen instead

Requesting a new rule? Please see Proposing a New Rule for instructions.

[silvenon]

1. When does this rule warn? Please describe and show example code:

   It warns when you use a wildcard import.

   import * as foo from 'foo';

2. Is this rule preventing an error or is it stylistic?

   Stylistic.

3. Why is this rule a candidate for inclusion instead of creating a custom rule?

   Not sure what this question means 😕

4. Are you willing to create the rule yourself?

   Yes.

[nzakas]

Why is this rule a candidate for inclusion instead of creating a custom rule?

In other words, why should this be part of the ESLint core and managed by us when you can write and manage it yourself?

[silvenon]

After giving it some more thought, I don't think it's a good rule to enforce. Forcing a single default export instead of named exports provides no benefit.

[michaelficarra]

That syntax doesn't import the default export, it imports all exports.

[silvenon]

Yes. I meant that not allowing wildcard imports will force you to write modules with a single (default) export.

[michaelficarra]

No it won't.

[silvenon]

// foo.js
export const a = 5;
export const b = 6;

// bar.js
import * as foo from 'foo'; // oops, error, fixing...
import foo from 'foo'; // but that won't work, gotta rewrite foo.js...

// foo.js
export default {
  a: 5,
  b: 6
};

// bar.js
import foo from 'foo'; // this works now
console.log(foo.a);

[silvenon]

Oh, I see what you meant, when you're importing only certain exports, it doesn't really matter whether it's a single exported object or a named export.