React-styleguidist: Support ES6 exports

Created on 13 Feb 2018  Â·  7Comments  Â·  Source: styleguidist/react-styleguidist

I see this issue was closed without any comments and also locked https://github.com/styleguidist/react-styleguidist/issues/633

Is there a reason only default exports are allowed and not named exports?
We're in a position to rely on ES6 exports to allow tree shaking and would rather not use default exports.

I was wondering if there is any wiggle room here or if you stand strong on this?

enhancement

Most helpful comment

@seivan thanks :). I had a dig around to try a more robust solution. I'm a bit puzzled by what I found.

Given this set up...

````jsx
// styleguide.config.js
module.exports = {
components: 'path/to/component.js',
};

// path/to/component.js
import React from 'react';

export const SomeComponent = () =>

Hello, I'm SomeComponent
;

// path/to/Readme.md

console.log(SomeComponent);

````

...I see in the console { SomeComponent: ..., __esModule: true}.

That suggests that the exports of /component.js are exposed as SomeComponent. That's kind of weird because SomeComponent is the name of one of the named exports, not the exports as a whole.

In this case, the following 'works'...

````js
// path/to/Readme.md

<SomeComponent.SomeComponent />

````

...which seems odd. Perhaps I'm missing something obvious here.

If a contributor is looking at this, I'm super happy to work on a potential fix. I could do with some help pointing to where the modules are exposed though. So far I've had a dig around Preview, evalInContext, examples-loader and associated files but I haven't had any joy.


UPDATE

I've just realised that it's probably styleguide-loader which deals with exposing the components. example-loader just sets up the examples, which consume components exposed by styleguide-loader.

Looking into styleguide-loader now.


UPDATE

Opened PR #825 adding limited support for named exports 🤞

All 7 comments

Yeah I thought the response to #633 was a little flat.

A lot of developers use only named exports for a bunch of reasons. eslint-plugin-import is in the process of adding a rule to prohibit the use of default exports.

Without this I need to hack styleguidist to make it usable.

@marcdavi-es Well if you're in a hurry, you can get around it with

const Button = require('./dist/Components/Button').Button;

But it's very error prone.

@seivan thanks :). I had a dig around to try a more robust solution. I'm a bit puzzled by what I found.

Given this set up...

````jsx
// styleguide.config.js
module.exports = {
components: 'path/to/component.js',
};

// path/to/component.js
import React from 'react';

export const SomeComponent = () =>

Hello, I'm SomeComponent
;

// path/to/Readme.md

console.log(SomeComponent);

````

...I see in the console { SomeComponent: ..., __esModule: true}.

That suggests that the exports of /component.js are exposed as SomeComponent. That's kind of weird because SomeComponent is the name of one of the named exports, not the exports as a whole.

In this case, the following 'works'...

````js
// path/to/Readme.md

<SomeComponent.SomeComponent />

````

...which seems odd. Perhaps I'm missing something obvious here.

If a contributor is looking at this, I'm super happy to work on a potential fix. I could do with some help pointing to where the modules are exposed though. So far I've had a dig around Preview, evalInContext, examples-loader and associated files but I haven't had any joy.


UPDATE

I've just realised that it's probably styleguide-loader which deals with exposing the components. example-loader just sets up the examples, which consume components exposed by styleguide-loader.

Looking into styleguide-loader now.


UPDATE

Opened PR #825 adding limited support for named exports 🤞

@marcdavi-es I just tested your idea, and as you said, it worked.

any update on this?

:tada: This issue has been resolved in version 6.5.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

Was this page helpful?
0 / 5 - 0 ratings