Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using @group causes 404 on load #244

Open
rocket-tyard opened this issue Jun 29, 2021 · 2 comments
Open

Using @group causes 404 on load #244

rocket-tyard opened this issue Jun 29, 2021 · 2 comments

Comments

@rocket-tyard
Copy link

Describe the bug
When I specify @group on components, the components are successfully split in the left nav, but the initial page that loads on vuese serve --open becomes:

Server running at http://127.0.0.1:5000/#undefined

Even if I am able to get a valid path opened, if I click on the "Components" header to return me to the index (e.g., http://127.0.0.1:5000/#) I still get the following in the browser in the right pane of the page:

404
The requested path could not be found

Note that if I click on any of the component items themselves that the correct markup loads and renders. But that initial load, or if the Components header is clicked, results in a 404.

To Reproduce
Steps to reproduce the behavior:

  1. In your Vue component descriptor, add @group Controls to any component. I was able to reproduce this with any control, whether it was first alphabetically or not. I also tried adding a group to all controls with the same result.
  2. Generate the docs with vuese gen
  3. Open the docs with vuese serve --open

Note that steps 2 and 3 were performed using npm with those scripts defined in the package.json.

Expected behavior
Either first component is opened in the browser, with any clicks on the Components header also redirecting to that component.

Or an index page can be defined in some way to be used as the Overview for the docs.

Screenshots
Screen Shot 2021-06-29 at 3 36 19 PM

Environmental information:
System:
OS: macOS 11.4
CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
Binaries:
Node: 14.4.0 - ~/.nvm/versions/node/v14.4.0/bin/node
npm: 6.14.5 - ~/.nvm/versions/node/v14.4.0/bin/npm
Browsers:
Chrome: 91.0.4472.114
Firefox: 88.0.1
Safari: 14.1.1

@rocket-tyard
Copy link
Author

I did find that adding one line to the reducer in getFirstPath in the index.js of the @vuese/cli file fixed the issue for me (though it's not clear to me why the reducer fails otherwise):

function getFirstPath(config) {
    const entryPath = path.resolve(`${config.outDir}/index.html`);
    const reg = /(?:[\s\S]+)sidebar\:([\s\S]+)\}\)/;
    const entrySourceStr = fs.readFileSync(entryPath, 'utf-8') || '';
    try {
        const regRes = entrySourceStr.match(reg)[1];
        const routesConfig = new Function(`return ${regRes}`)();
        const firstRoute = routesConfig.reduce((p, v, i) => {
            if (i === 0) {
                const { links } = v;
                return links[0] && links[0].link
            }
            return p;
        }, '');
        // Read the first preview configuration injected when opening the browser.
        return `#${firstRoute}`;
    }
    catch (e) {
        // If there's an error, follow the previous logic.
        return '';
    }
}

The only change here is that I return p when the index is not 0.

@carlovenus
Copy link

+1 Same issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants