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?
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 = () =>
// 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.
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.
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?
@kopax There's an attached PR https://github.com/styleguidist/react-styleguidist/pull/825
:tada: This issue has been resolved in version 6.5.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
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 = () =>
// path/to/Readme.md
````
...I see in the console
{ SomeComponent: ..., __esModule: true}.That suggests that the exports of
/component.jsare exposed asSomeComponent. That's kind of weird becauseSomeComponentis 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
````
...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-loaderand associated files but I haven't had any joy.UPDATE
I've just realised that it's probably
styleguide-loaderwhich deals with exposing the components.example-loaderjust sets up the examples, which consume components exposed bystyleguide-loader.Looking into
styleguide-loadernow.UPDATE
Opened PR #825 adding limited support for named exports 🤞