CLI: Re-Add Nuxt support #28607
CLI: Re-Add Nuxt support #28607
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit bf7484a. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 1 targetSent with 💌 from NxCloud. |
|
@tobiasdiez
|
|
@tobiasdiez npx nuxi@latest init (pnpm) @ndelangen This might be CPC related, though. |
|
Thanks for this PR and your tests!
I can reproduce it as well. The problem is that in our setup Simplest solution: just add More involved solution: make it possible that presets return a javascript object as builder, instead of only a module name. (Similar to how eslint v9 is handling plugins now). Do you have any preference, or another idea? |
I've fixed this already in the main branch by adding lodash to optimizeDeps: |
@tobiasdiez Take a look at https://github.com/storybookjs/storybook/blob/next/code/frameworks/angular/src/preset.ts#L31. You can see that you can also just pass an absolute path as a value. With this approach, you make sure that |
|
Many thanks. This worked like a charm! 🚀 In nuxt-modules/storybook#729, I've now also added e2e tests (using this PR here to add storybook to a nuxt starter). Running |
|
@valentinpalkovic @tobiasdiez Maybe it is best if we have Nuxt sandbox over here: |
|
@tobiasdiez As Kasper mentioned, we could add Nuxt to our sandboxes, and you could test the sandbox on this PR and rerun it every time you release a new Canary version. Otherwise, I don't see an easy way to copy over our test suite setup to your repository. |
|
Hello @tobiasdiez do you have any news when this draft will be merged ? |
|
@kasperpeulen @valentinpalkovic Thanks for the suggestion. Adding a sandbox would indeed give some confidence that things are working, but I was hoping for a solution that we can apply in downstream projects (e.g. that PRs to the nuxt storybook addon are not breaking things). Similar to https://www.npmjs.com/package/@apollo/server-integration-testsuite. @KeremTurkyilmaz We first need to fix the major bugs in the nuxt module. Help moving this forward is of course very welcome! |
|
@tobiasdiez Unfortunately, we don't have a dedicated testsuite solution like Apollo does. :/ |
|
We do have default stories in https://github.com/nuxt-modules/storybook/tree/main/packages/storybook-addon/template/cli, but I have no idea how they get installed nor why this would fail in the sandbox. If you give me some pointers where to start, I can look into this. |
|
Can we please get this in as soon as possible? We constantly have people opening issues at the nuxt-storybook module because they configured something wrong. Having the cli integration would make setting this up with nuxt way easier and robust. 🙇 The problem with the sandbox might come from the fact that we don't add the stories under the |
|
@storybookjs/core, we would greatly appreciate support from the core team regarding the Nuxt-Storybook integration. @chakAs3 and I are working on this in our free time, and unfortunately, we don't have the resources to continually address new issues that arise in the Nuxt module due to upstream changes in Storybook. Many of these issues could be avoided if the Nuxt integration sandbox were included in your test suite. Additionally, our installation instructions are more complex than necessary because the Storybook CLI still doesn't fully recognize Nuxt projects. Thus new users make mistakes during the setup, and then open issues at the nuxt repo adding to our workload. It would be incredibly helpful if we could get this PR merged as soon as possible. Could you also review my pending PRs at your earliest convenience? (https://github.com/storybookjs/storybook/pulls/tobiasdiez) If you believe my approach in a PR isn't the right solution (e.g., PR #29172 comment or PR #28595), that’s completely understandable. However, it would be immensely helpful if you would then implement an alternative solution (or at least suggest one). These PRs are not just for theoretical improvements; they address critical issues that make maintaining the Nuxt integration extremely challenging. Thank you for your time and consideration! |
|
I have informed the core team and we will try to prioritise this and the mentioned PRs asap. |
|
Yes, this has become quite challenging for users. Just last week, I helped a company manually set up Storybook on a large Nuxt project. I had previously built a custom CLI for this, but stopped maintaining it due to the difficulty of keeping it in sync with Storybook's frequent releases. @tobiasdiez, on a related note, I’m encountering consistent failures when building and publishing Storybook to Chromatic, likely due to the large number of components and insufficient RAM. Have you come across this issue, and is there a recommended solution? |
I've never experienced such issues with the chromatic-workflow setup in the storybook-nuxt-module repo. I would love to migrate my own projects to the nuxt-module (and thus gain more experience with publishing it to chromatic), but that's currently blocked by various bugs in Storybook. |
|
I talked to the team, and currently, we are wrapping up the 8.4 release. Next week, I will get the chance to take a proper look and hopefully get the PR merged. |
It works fine on small or medium-sized projects i guess, but the one I’m working on now has hundreds of components, i only started by creating stories for few components. I’m wondering if Storybook’s build process is handling all the components, even those without stories, when generating the static files ? which causing the memory issue |
|
Finally taking a look... |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
17 file(s) reviewed, 19 comment(s)
Edit PR Review Bot Settings | Greptile
valentinpalkovic
force-pushed
the
revert-28479-revert/26884
branch
from
91a536a
to
4ca546b
Compare
|
Hi @tobiasdiez Our CI is finally green. There is one caveat, though. When generating a sandbox, it does not contain our default stories (Button, Header, Page), which some of our e2e-production tests require. Therefore, I was forced to disable our e2e-production tests on the nuxt sandbox. If you add the default stories to https://github.com/nuxt-modules/storybook/tree/main/packages/storybook-addon/template/cli, we may be able to reactivate the e2e-production tests. |
Awesome! Thanks for you work!
I'm not so sure if that's a good idea. Sure, for e2e tests it makes a lot of sense to have these standard stories. However, as a user of the nuxt module these auto-generated files are mostly noise and I think most users would immediately delete them. Is it possible that you use the vue-package to generate the stories for the e2e tests here in this repo? (By the way, it would perhaps be an improvement for the on-boarding if instead of auto-generating Buttons and similar controls that are not really useful, these would be provided by the storybook package - similarly, how nuxt provides the welcome screen that we show in the storybook. Then storybook init would only generate one or two stories that show users how everything works.) |
They are meant to be serve as examples stories that once you have looked, you can delete indeed.
Can you elaborate on that? I don't really follow. |
|
Sorry, I wrote that in a bit of a hurry. Currently, if you run import { fn } from '@storybook/test';
import type { Meta, StoryObj } from '@storybook/vue3';
---- only change here
// Change the following to import the actual component, e.g. './Button.vue'
import Button from '@storybook/vue3/mocks';
----- end of change
// More on how to set up stories at: https://storybook.js.org/docs/writing-stories
const meta = {
title: 'Example/Button',
component: Button,
// This component will have an automatically generated docsPage entry: https://storybook.js.org/docs/writing-docs/autodocs
tags: ['autodocs'],
argTypes: {
size: { control: 'select', options: ['small', 'medium', 'large'] },
backgroundColor: { control: 'color' },
},
args: {
primary: false,
// Use `fn` to spy on the onClick arg, which will appear in the actions panel once invoked: https://storybook.js.org/docs/essentials/actions#action-args
onClick: fn(),
},
} satisfies Meta<typeof Button>;
export default meta;
type Story = StoryObj<typeof meta>;
/*
*👇 Render functions are a framework specific feature to allow you control on how the component renders.
* See https://storybook.js.org/docs/api/csf
* to learn how to use render functions.
*/
export const Primary: Story = {
args: {
primary: true,
label: 'Button',
},
};
export const Secondary: Story = {
args: {
primary: false,
label: 'Button',
},
};
export const Large: Story = {
args: {
label: 'Button',
size: 'large',
},
};
export const Small: Story = {
args: {
label: 'Button',
size: 'small',
},
}; |
|
Non-starter. We did that originally and docgen doesn't work well unless we have the source code. I agree the current situation is non-ideal though. Next year I'd like to transition to an onboarding experience where the user provides their own components instead of these throwaways. However, we'll need to do a bunch of work to make that experience smooth for users. |
Can't we just have a flag to generate those files so users don't ever see them and the sandbox can use them for testing? It would only require making changes to Am I missing something here? Also, is that the only thing blocking this PR from being merged? |
|
@hacknug I think we should go for something like that. Making sure both CI in storybook works, and the nuxt framework is not forced to use it for Another way might be to just somehow hardcode in the CLI that the nuxt generator always get the cli templates from the vue3 package when sandboxes are generated. |
What I did
Reverts #28479
Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
Manual testing
This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!
Documentation
MIGRATION.MD
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal,ci:mergedorci:dailyGH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli/src/sandbox-templates.tsMake sure this PR contains one of the labels below:
Available labels
bug: Internal changes that fixes incorrect behavior.maintenance: User-facing maintenance tasks.dependencies: Upgrading (sometimes downgrading) dependencies.build: Internal-facing build tooling & test updates. Will not show up in release changelog.cleanup: Minor cleanup style change. Will not show up in release changelog.documentation: Documentation only changes. Will not show up in release changelog.feature request: Introducing a new feature.BREAKING CHANGE: Changes that break compatibility in some way with current major version.other: Changes that don't fit in the above categories.🦋 Canary release
This pull request has been released as version
0.0.0-pr-28607-sha-b9bf7d39. Try it out in a new sandbox by runningnpx storybook@0.0.0-pr-28607-sha-b9bf7d39 sandboxor in an existing project withnpx storybook@0.0.0-pr-28607-sha-b9bf7d39 upgrade.More information
0.0.0-pr-28607-sha-b9bf7d39revert-28479-revert/26884b9bf7d391721048903)To request a new release of this pull request, mention the
@storybookjs/coreteam.core team members can create a new canary release here or locally with
gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=28607Greptile Summary
This PR reverts the removal of Nuxt support in Storybook, restoring functionality that was previously removed due to QA issues before the 8.2 release.
detect.tsandproject_types.ts, using@storybook-vue/nuxtpackagegenerators/NUXT/index.ts, including@nuxtjs/storybookmodule integrationnuxt-vite/default-tsmarked asinDevelopmentwith Vite builderThe changes appear comprehensive but lack test coverage and documentation updates that should be addressed before merging.