Rule proposal: default-export-function-style

[sindresorhus]

Whether to prefer a default export as a named function or a const variable with an arrow function.

It should default to function style.

It should be auto-fixable.

Fail

// "unicorn/default-export-function-style": ["error", "function"]

const foo = () => {};
export default foo;

// "unicorn/default-export-function-style": ["error", "variable"]

export default function foo() {}

Pass

// "unicorn/default-export-function-style": ["error", "function"]

export default function foo() {}

// "unicorn/default-export-function-style": ["error", "variable"]

const foo = () => {};
export default foo;

---

Open question. What should happen to:

export default () => {};

Should we have a separate style for that or just disallow it for both function and variable style?

[fregante]

Open question. What should happen to:

I think that that code won’t pass an existing rule already: https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-anonymous-default-export.md

Also #154

[sindresorhus]

I think that that code won’t pass an existing rule already: https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-anonymous-default-export.md

I'm aware, but we cannot assume other rules. We need to decide how to handle that case.

[fregante]

Then I think it should be covered by the “function” style

[fregante]

I don’t think it should be called "function/variable" however, they're all functions:

function foo() {}
const foo = () => {}
let foo = function () {}

Maybe these are inline:

export default function () {}
export default function foo () {}
export default () => {}

And this should be pre-defined or something:

export default foo; // However the `foo` function is defined is irrelevant

---

Discussing this rule further:

Do you want to apply the same rule to classes? export default class {}? Objects? Where does it stop? export default 4 instead of const n = 4; export default n;?

Maybe the logic should be: if it can be inlined and named at the same time, then it should be part of this rule. As far as I know only functions and classes can be that (in the example above, 4 will lose its n name for example, so this rule can’t be applied there)

[sindresorhus]

Sounds good. How about statement and inline?

[sindresorhus]

Do you want to apply the same rule to classes? export default class {}? Objects? Where does it stop? export default 4 instead of const n = 4; export default n;?

I think it makes sense for classes, but not objects or variables.

Maybe we should just do an options-object?

{
	functions: 'statement',
	classes: 'statement',
	objects: 'inline',
	values: 'inline'
}

[fregante]

If we agree with import/no-anonymous-default-export I don’t think it’s worth your time to implement something you’re not going to use (objects: inline, for example), but that’s up to you. I’d limit it to classes and functions and a single configuration string: ['error', 'inline'/'statement']

[sindresorhus]

I’d limit it to classes and functions and a single configuration string: ['error', 'inline'/'statement']

Alright. Let's try that first.

[fisker]

Personally I don't use inline (except some really simple functions), what style do you use? @fregante @sindresorhus

[fregante]

I use inline exports all the time. For defaults, I still prefer inline exports if they can be named inline (functions, classes)

[sindresorhus]

I used to prefer non-inline so I could use arrow functions, but lately I'm preferring inline export default function foo () {}.