Syntax considerations: Default and named exports

[sodic]

JavaScript generally offers two approaches to importing and exporting names across modules.

The first option is using named exports/imports:

// foo.js
export function foo() {
  // ...
}

// main.js
import { foo } from 'foo';

And the second option is using default exports/imports:

// foo.js
export default function foo() {
  // ...
};

// main.js
import foo from 'foo';

Wasp currently uses (in its generated code) and recommends (through documentation and examples) the default exports approach. This issue outlines why I think we should reconsider this.

---

Many developers discourage default exports, and some are even in favor of completely removing them. These two articles (here and here) do a great job of explaining all the reasons behind such a seemingly radical decision. Essentially, default exports don't offer any benefits over named exports but come with several significant downsides. The two mentioned articles elaborate on most of them. Here is their TL;DR:

• Default imports make tree-shaking less efficient
• Named imports come with better DX and tooling support
• Refactoring/changing names becomes more difficult with default imports
• Default imports require more side trips (to either the module's documentation or its source)
• Default imports exhibit several name-matching issues
• Named imports require explicit renaming, while default imports do this implicitly
• Named imports report helpful errors

I want to add two more points to the list:

More refactoring issues

Default exports make refactoring and IntelliSense needlessly complicated in one way the articles don't mention. For example, let's say you have the class Foo. This how it's imported in other files:

import Foo from './Foo';

If you wanted to change the class' name to Bar, you would go to its definition file and do it using the IDE's renaming functionality, which also changes the file name to Bar.ts (as it should). This is how user files look after the change:

import Foo from 'Bar';

The same problem happens in the opposite direction (i.e., renaming something in the user code).

Better tooling support (but this time, we're the tool)

Because of everything listed above, Wasp will most likely have an easier time providing support and IntelliSense for named imports/exports.

[Martinsos]

Ha very interesting @sodic ! Thanks for this, I have never considered this deeply, but it all sounds very reasonable, and I am in for preferring named exports in Wasp over default ones. I believe the main motivation was that when a certain file exports one single thing, it feels a bit weird to import it as named export. But we can do it , no problem!

How should we go about this? Should we not touch anything for now and then try to make this changes as we encounter those parts of the code? Or would you like to give it a try now, update how Wasp exports stuff? It would be a breaking change but that is ok at this stage.

[sodic]

@Martinsos I probably wouldn't touch anything for now since our code is still changing rapidly. We can make the changes and update the docs as we encounter them.