Live data from Hacker News

Why we have banned default exports in JavaScript

blog.neufund.org

71–76 of 76 posts

Re: Why we have banned default exports in JavaScript

#71

The historical claim, that default exports we're introduced for compatibility with CommonJS/Node, is not accurate. Default exports were introduced because often a module wants to export a single value or piece of functionality. In such cases, in module systems where all exports are named, the author of the module and its consumer have to coordinate on some convention to indicate "this is the thing". For example, some…

If default exports are meant to help export only a single value from a module, how come they allow also exporting other values alongside the default value?

Re: Why we have banned default exports in JavaScript

#72
post #49

Two of the three reasons listed involve refactoring and autocomplete quirks of Visual Studio Code, specifically. For instance, Webstorm has no such issues with default exports. It is smart enough to find all uses of a module and to track them down. The third reason is not all that common in my experience. Tree shaking is an optimization and often a premature one. It's also a technique primarily used for third party l…

In webstorm/intellij say you have a react component, one export per module as you say. The import statements are a tie imo to write by hand: import MyThing from "../../components/editors/MyThing"; import {MyThing} from "../../components/editors/MyThing"; But if it's named, you don't need to stop what you're doing, scroll to the top of the file, type out the import statement by hand, and look over at your code tree an…

You shouldn't code around your tools. Your tools are there to serve you, not the other way around. Also, devs on my team use vim, Sublime, Atom, VS Code, Webstorm/IntelliJ, and many more. They all work radically different for things like this.

Re: Why we have banned default exports in JavaScript

#73
While reading this thread away from my machine, I'm curious now what happens when

export default { foo: 2 };

export const foo = 3;

// other file

import { foo } from './file'

console.log(foo);

Presumably last one wins or, if the other way around, a reassignment of const error?

Re: Why we have banned default exports in JavaScript

#74

While reading this thread away from my machine, I'm curious now what happens when export default { foo: 2 }; export const foo = 3; // other file import { foo } from './file' console.log(foo); Presumably last one wins or, if the other way around, a reassignment of const error?

3 is logged into the console without any warning / error.

Re: Why we have banned default exports in JavaScript

#75
post #74

While reading this thread away from my machine, I'm curious now what happens when export default { foo: 2 }; export const foo = 3; // other file import { foo } from './file' console.log(foo); Presumably last one wins or, if the other way around, a reassignment of const error?

3 is logged into the console without any warning / error.

Thanks

Re: Why we have banned default exports in JavaScript

#76

While reading this thread away from my machine, I'm curious now what happens when export default { foo: 2 }; export const foo = 3; // other file import { foo } from './file' console.log(foo); Presumably last one wins or, if the other way around, a reassignment of const error?

export default { foo: 2 };

is not the same as:

module.exports = { foo: 2 };

The way your example would translate to commonjs is:

module.exports = { default: { foo: 2 }, foo: 3 }

Post reply on HN