search

storybookjs / storybook

Storybook is the industry standard workshop for building, documenting, and testing UI components in isolation
https://storybook.js.org
MIT License
84.12k stars 9.25k forks source link

Build: Selectively publish packages #9160

Open shilman opened 4 years ago

shilman commented 4 years ago

NPM publish is failing with a higher frequency in recent weeks. To minimize this, I propose publishing a subset of packages.

Why

NPM publishing fails intermittently due to unknown server issues. In each case, the server returns a PUT 200 on publish, but the package is subsequently unavailable, either from the command-line NPM or the web interface, or both. This is a server issue, because an identical publish can succeed minutes later.

In recent weeks the servers seem to be less stable than usual. Also, we are publishing more packages. Recent failures include 5.3.0-beta.7, beta.17, beta.23, beta.26, beta.27. See https://github.com/storybookjs/storybook/blob/next/CHANGELOG.md for details.

This is a problem for users and also for maintainers.

What

I propose only publishing a subset of the packages:

package count
@storybook/addons 5735915
@storybook/client-logger 5664607
@storybook/channels 5630934
@storybook/components 5588912
@storybook/core-events 5324992
@storybook/theming 4957992
@storybook/router 4758446
@storybook/channel-postmessage 4737895
@storybook/node-logger 4508624
@storybook/ui 4494679
@storybook/core 4449319
@storybook/api 4256386
@storybook/client-api 4074830
@storybook/addon-actions 3894188
@storybook/react 3722386
@storybook/addon-knobs 2924045
@storybook/addon-links 2535738
@storybook/addon-viewport 1395532
~@storybook/addon-info~ 1269880
@storybook/addon-a11y 813777
@storybook/addon-notes 789766
@storybook/source-loader 738132
@storybook/addon-storyshots 733029
@storybook/addon-storysource 728057
@storybook/addon-options 643882
@storybook/addon-backgrounds 388060
@storybook/codemod 385430
@storybook/addon-docs 371426
@storybook/addon-centered 352408
@storybook/cli 342060
@storybook/vue 306995
@storybook/channel-websocket 239645
~@storybook/react-native~ 233926
@storybook/angular 175695
@storybook/html 108007
@storybook/addon-jest 84762
@storybook/addon-storyshots-puppeteer 79237
~@storybook/addon-ondevice-knobs~ 76207
~@storybook/react-native-server~ 72287
@storybook/addon-contexts 49376
~@storybook/addon-ondevice-notes~ 38904
@storybook/postinstall 34439
~@storybook/addon-cssresources~ 26629
@storybook/ember 26082
~@storybook/addon-ondevice-actions~ 23295
~@storybook/addon-events~ 20631
~@storybook/polymer~ 13952
~@storybook/preact~ 10765
~@storybook/addon-graphql~ 9915
~@storybook/addon-ondevice-backgrounds~ 9693
@storybook/svelte 7047
~@storybook/mithril~ 5781
~@storybook/marko~ 5534
~@storybook/addon-google-analytics~ 5377
~@storybook/riot~ 4684
@storybook/web-components 3847
~@storybook/addon-design-assets~ 3504
~@storybook/addon-queryparams~ 2845
~@storybook/rax~ 2278
~@storybook/addon-parameter~ 1963
~@storybook/addon-roundtrip~ 1954
~@storybook/addon-decorator~ 1943
~@storybook/addon-preview-wrapper~ 753
@storybook/addon-essentials 121

This should reduce the number of packages by about 1/3. Which will hopefully also reduce the publish failures by a similar amount. In a subsequent step, I'd like to remove some of the packages from the monorepo entirely.

How

lerna --force-publish can take a list of packages to publish. I propose a blacklist, skip-publish.txt, containing the above packages, and filter those out from the publishing process.

pksunkara commented 4 years ago

What's the criteria used for selecting packages to be blacklisted or moved away from the repo? We have seen how useful a monorepo is, I am just worried that we are trying to solve a problem by doing something entirely different.

I think the main issue we are having is we rely on prerelease packages. When one of the package is missing, the other packages don't gracefully fail and work because of this. If we fix this process, then we should be good.

shilman commented 4 years ago

I'm proposing this also as a first step towards moving these packages out of the monorepo. How do you propose not relying on prerelease packages?

pksunkara commented 4 years ago

first step towards moving these packages out of the monorepo

Why is that? The development process would become much more complex, wouldn't it? There will be a lot of time wasted waiting for dependencies to be published first so that the CI in other packages would pass first etc....

valentinpalkovic commented 1 year ago

@shilman Is this issue still relevant or can we close it?