Description
Consider the following:
components/foo.js:
export default class Foo extends React.Component {
render() {
// ...
}
}widgets/foo.js:
import FooComponent from '../components/foo';
export default class Foo extends BaseWidget {
constructor() {
super(FooComponent);
}
// ...
}Foo (in components/foo.js) and FooComponent are exactly the same thing, but have been renamed via default import/export. When one thing has two or more names, it increases the difficulty of comprehending code, especially when there are many functions, classes, etc. that are renamed on import.
The proposal is to have a rule that generates a warning or error when a default import is given a different name than a default export.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
Participants
Activity
ljharb commentedon Mar 12, 2018
This is a valuable part of both default and named import syntax (the ability to rename things), and I’m not sure why it’s an issue that needs a rule.
steve-taylor commentedon Mar 12, 2018
It’s an issue for the reasons outlined above. There are already plenty of rules that, when applied, restrict the usage of language capabilities that some people may find useful. It’s a matter of preference.
ljharb commentedon Mar 12, 2018
What would happen when you wanted to use the Foo component and widget in the same file?
Separately, i think that it’s not at all apparent that it’s more difficult to comprehend code when something has a different name in different files; the point of a module is that you think about one module (file) at a time.
steve-taylor commentedon Mar 12, 2018
At that point, I'd consider naming things more appropriately. For example, I'd look at adopting a naming convention whereby widgets are suffixed by
Widget(e.g.FooWidget).As a last resort, there's always
// eslint-disable-line: import/no-rename-default, but it's unlikely to be used when a naming convention is in place.steve-taylor commentedon Mar 12, 2018
Let's also consider the following case (and I've been guilty of this before):
This can come about as my understanding of the scope, purpose and/or context of a function/class evolves while building it and using it for the first time. It would be nice to have a linting rule to remind me to clean this up by enforcing uniformity between its declared name and its imported name.
For those who don't see this as an issue, they can simply choose not to use this rule, like any other stylistic rule.
steve-taylor commentedon Mar 12, 2018
It would be nice if feature tickets and modules were nicely aligned. In reality (team of 5+ devs working on the same rapidly evolving codebase), implementing a feature typically involves reading, comprehending, and even modifying numerous modules. Hopefully you can appreciate that this proposal has come about based on a real dev team pain point rather than a contrived stylistic need.
ljharb commentedon Mar 13, 2018
It's also important to note that a default export need not have a name at all, consider
export default () => {}orexport default class { }- what would your rule do in that case?Effectively this rule would disable a major feature of the language, the ability to rename imports (you're only requesting the default, but presumably it could apply to named as well via an option).
Perhaps you could share more about the pain points you hope to solve?
steve-taylor commentedon Mar 13, 2018
These rules also disable major features of the language:
import/no-anonymous-default-export- cannotexport default () => {}, for exampleno-default-export- noexport defaultat allimport/no-unassigned-import- disables polyfillsWill they be removed?
Ignore these exports. Use it with
import/no-anonymous-default-exportto ensure that never happens.ljharb commentedon Mar 13, 2018
@steve-taylor fair point on existing rules that do that.
Can you explain more about the pain points? "it increases the difficulty of comprehending code" isn't something I've seen, on very large codebases, so I'd love something a bit more concrete to motivate this rule.
steve-taylor commentedon Mar 13, 2018
You’re smarter than me, then! The issue is that when there are a number of similarly named functions with a similar purpose that return the same type of object, but they are inconsistently named in default exports vs imports, it makes it more difficult than it needs to be to build a mental model of complex code. Same goes for classes. When one function or class has two names, it’s unnecessary noise, which is never a good thing when you’re reading code.
It’s hard to provide a less abstract example without handing over my employer’s code.
If you’re trying to figure out whether the effort is justified, I can save you most of the effort by submitting a pull request.
ljharb commentedon Mar 14, 2018
The effort I'm concerned about is future maintenance, not just the actual PR :-) Certainly it would be awesome if you were able to submit a PR if the request becomes accepted.
The readability issues you're talking about only apply when multiple of these similarly-named items are used in the same file? If so, wouldn't renames, in that file, actually help understand what the code is doing?
steve-taylor commentedon Mar 14, 2018
Not the same file. Spread throughout the same project.
ljharb commentedon Mar 14, 2018
I'm confused; when do you need a mental model beyond the file you're currently looking at, and its direct dependencies?
23 remaining items