feat: add a default export

[laggingreflex]

This adds a default export object containing all named exports.

Eg.:

// @create-index

export king from './king.js'
export queen from './queen'
export default {
  king,
  queen
}

Fixes #11

Keeps camelCase support from #16

[laggingreflex]

Above doesn't work, it actually needed to be more like this. Fixed.

// @create-index

import _king from './king.js';
export const king = _king;

import _queen from './queen';
export const queen = _queen;

export default {
  king,
  queen
}

[laggingreflex]

@gajus What are your thoughts on this? #27 build on top of this a lot, rebasing it against this would be a lot different than rebasing it against current master. Let me know if you're happy with this. If so I can actually merge this and #27 together.

[gajus]

feat: add a default export

What is the reason for wanting this?

This breaks static analyses, i.e. it invalidates the purpose of using ES modules in the first place. Default exports should be avoided whenever possible.

[laggingreflex]

It fixes #11. Copying the relevant part of the problem:

For example

proj
├── king.js
└── queen
    ├── bar.js
    └── foo.js

creates

proj
├── king.js
├── index.js
└── queen
    ├── index.js
    ├── bar.js
    └── foo.js

where queen/index.js is correct (as long as only named exports are imported from it):

// proj/queen/index.js
export bar from './bar.js';
export foo from './foo.js';

but proj/index.js isn't

// proj/index.js
export king from './king.js';
export queen from './queen'; // < because queen has no default export

This adds a default export to queen/index.js

// proj/queen/index.js
import _bar from './bar.js';
export const bar = _bar;

import _foo from './foo.js';
export const foo = _foo;

export default {
  foo,
  bar
}

Without this create-index is incompatible with itself. Recursive (creating) indexing also wouldn't work if it encounters an index created with create-index which will cause the above (queen) problem.

[gajus]

If I have a project structure such as:

./
├── king.js
├── index.js
└── queen
    ├── index.js
    ├── bar.js
    └── foo.js

Then I expect to be able:

import {king} from './';
import {bar, foo} from './queen';

Anything else, e.g. import {queen} from './' is invalid use case.

Invalid in a sense that it invalid use of static analyses and possibility of using shaking. Of course, correct me if I am wrong.

My assumptions are based on the knowledge of existing mechanisms used to transpile the code, namely babel-plugin-transform-es2015-modules-commonjs and how webpack and rollup handles dependency resolution.

[laggingreflex]

You're right it does promote bad design.