Test cases should not encourage default exports

When designing an ES6 module, the developer has two ways of exposing internal functions and values: named exports and default exports. Depending on the method used, the corresponding import statement looks a little different too. However there are various articles outlining the opinion that using default exports is an anti-pattern should be avoided.

I’m only a little way into the ECMAScript challenges, but many of the test cases I’ve come across require the default export method to be used, which I don’t think should be encouraged for many reasons.

For example take the Armstrong Numbers challenge. This challenge only requires the developer to export one function, validate. The test script consumes the function like this:

import ArmstrongNumber from './armstrong-numbers';

It then uses the function like this:

ArmstrongNumber.validate(input)

In order for the submission to pass the unit tests, the validate function has to be exported as a default export.

An alternative way of doing this is to consume the validate function like this:

import {validate} from './armstrong-numbers';

And consume it like this:

validate(input)

For the consuming module, this is a lot less typing. For the submitter the only change is that they don’t have to type ‘default’.

The Run Length Encoding exercise does this right:

import { encode, decode } from './run-length-encoding';

Not only is this less typing, but in a real-world scenario the first style will break the tree-shaking routines that are common in production code. For these and other reasons, I don’t think these exercises should be encouraging this pattern and should just consume the named function directly.

I’ve seen that there was some discussion on here about exporting classes, but I’ve not seen anything on this particular subject. I’m happy to submit refactored test cases myself. Would you be happy to accept them?

[tejasbubane]

Ok I am working on a PR to change them.

[SleeplessByte]

Closed by #599, Follow up #600