Kyle Suss
Kyle Suss
It seems like we should let CI get the full output to increase debugging opportunities for customers.
When a parsing error happens on a story's parameters, any errors during this process could use more context around the specific story that caused the issue. I had a customer...
Not sure of the feasibility of this (it seems possible to me) but is it possible to surface component errors during the CLI build? I'm talking about things that don't...
I received a support request with the following CLI failure details: ``` "errorType": "FetchError", "errorMessage": "✖ Failed to authenticate\nrequest to https://index.chromatic.com/graphql failed, reason: self signed certificate in certificate chain" ```...
Currently there is no way to customize this component since it does not pass down props.
This is an easy thing to miss in PR reviews. Maybe there is a nice way to automate checking for multiple versions in our CI.
Importing `global` into certain files can have some naming conflicts, so this should be updated to something more unique.
Mocking prismjs was a bit difficult in one of the consumers. I tried this in the test file: ```javascript jest.mock('prismjs/components/index'); jest.mock('prismjs', () => ({ highlightAllUnder: jest.fn(), })); ``` Sadly that...
It will be similar to the current global styling docs, but should focus on Storybook context (a decorator for the `GlobalStyle` component). Also worth calling out the `loadFontsForStorybook` function that...
Add a CI step to check the stories for any missing props. This will help ensure quality of the deployed Storybook. We have used Storyshots for this in the past.