Move js dependencies required for storybook into their own workspace

[eugene-manuilov]

Feature Description

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The package.json file is updated to have storybook in the workspaces array.
• JavaScript dependencies that are needed for storybook to function properly are moved to the new workspace.
• GitHub actions for storybook are updated accordingly to continue running it for all PRs.
• The storybook config property is moved from the main package.json file to the workspace package.json.

  site-kit-wp/package.json

  Line 80 in 37b72fa

  "storybook_wordpress_version": "5.5.1",

Implementation Brief

Creating the assets workspace

• Update the root package.json file to include "storybook" in its workspaces array.
• Create a new package.json file in the storybook folder using npm init -w ./storybook.
  • Copy all scripts used to build and run storybook into the new workspace package.json.
  • Include duplicate packages required to build the app that were added to the assets workspace in Move js dependencies required to build assets into their own workspace #10092.
  • We can now remove the puppeteer packages from the root package.json RE this comment.
  • Fix paths and ensure the commands work correctly after the refactor.
• Scan all dependencies that we have in the main package.json file and move all dependencies that are used in storybook to its own package by uninstalling them in the main package.json file and installing with -w ./storybook argument to specify the correct workspace.
  • Note: as this is the final ticket of the workspaces refactor, there should no longer be dependencies defined in the root package.json
• Update the package.json file to proxy storybook commands to the correct workspace using the npm run ... -w ./storybook approach.

Create a check for mismatched asset build package versions

As some of the core plugin build commands are used in both the assets and storybook workspace, we need to ensure they match. For now we can use a GH check, in future we can explore setting the assets workspace as a dependency of the storybook workspace.

• Create a new script and GitHub action which runs when either package.json or storybook/package.json are modified, checking for any mismatched versions for packages that build the core assets.

Test Coverage

• N/A

QA Brief

Changelog entry

[techanvil]

Hi @hussain-t, thanks for drafting this IB. It's mostly looking good, but I am a bit unsure about this point (presumably you mean copying the scripts for running Storybook, but that's not what I am unsure about):

Copy the scripts for the storybook but not for building the storybook to this new package.json.

Considering the build:storybook NPM script runs build-storybook, which is provided by the @storybook/react package, and also specifies the .storybook folder as its config location, if we keep build:storybook at the root level we'll need to keep the Storybook package(s) installed at the root level too, which partially defeats the point of moving Storybook to a workspace. We might also need to retain additional root level packages depending on how the config resolves things.

I think we should move all Storybook scripts into the workspace package.json. We should probably still output to dist in the repo root for now though, to keep the migration easy to manage, although at some point it would be nice to move all the workspaces to separate folders under a root workspace folder and we might want to output to a separate dist folder at that point...

Also, regarding this point:

Scan all dependencies that we have in the main package.json file and move all dependencies that are used in storybook to its own package by uninstalling them in the main package.json file and installing with -w ./.storybook argument to specify the correct workspace.

That mostly works, but we need to take care to ensure that shared dependencies (e.g. @wordpress/element & the underlying react) are managed correctly with matching versions. We need to check that common dependencies of the packages we install for Storybook match with those that are installed at the root level, and we might need to install packages like @wordpress/element at the workspace level while leaving it in the root package.json.

Alternatively, maybe we can simply leave our @wordpress/* packages, and so forth, in the root package.json and not specify them in the workspace version. I'm not sure if we'd run into any problems taking that approach... 🤔 This would be worth exploring further at the IB stage to make sure we identify the correct way forward.

[techanvil]

That mostly works, but we need to take care to ensure that shared dependencies (e.g. @wordpress/element & the underlying react) are managed correctly with matching versions. We need to check that common dependencies of the packages we install for Storybook match with those that are installed at the root level, and we might need to install packages like @wordpress/element at the workspace level while leaving it in the root package.json.

Alternatively, maybe we can simply leave our @wordpress/* packages, and so forth, in the root package.json and not specify them in the workspace version. I'm not sure if we'd run into any problems taking that approach... 🤔 This would be worth exploring further at the IB stage to make sure we identify the correct way forward.

Actually, thinking about it we're going to run into the same sort of issue in #10092 - essentially, we need to make sure our versions of packages used by the files in assets/js match for the storybook and assets workspaces, or that we only specify the dependencies in a single location.

Working on this issue and #10092 in parallel could lead to conflicts, I think it would make sense to do one after the other. I've gone ahead and made this issue a dependency for #10092.

[eugene-manuilov]

@hussain-t, i have updated AC to move storybook config as well. Plus, pay attention that .storybook is going to be renamed to storybook in #10090 because a workspace name can't start with a dot.

[benbowler]

Note that once #10113 is merged this ticket can move puppeteer and puppeteer-core to the workspace package.json files.

[techanvil]

Note that once #10113 is merged this ticket can move puppeteer and puppeteer-core to the workspace package.json files.

Thanks @benbowler, did you mean to link to a different issue though?

[benbowler]

@techanvil similar looking number but I meant: #10013

[techanvil]

Hey @benbowler, please see this #10092 (comment) with reference to the IB for this issue.

[benbowler]

Thanks @techanvil, replied in #10092 (comment) and updated based on the concept of duplicating dependencies and creating a script here to check shared package versions.

[techanvil]

Thanks @benbowler! The IB is mostly there, I just have a couple of points for consideration:

As some of the core plugin build commands are used in both the assets and storybook workspace, we need to ensure they match. For now we can use a GH check, in future we can explore setting the assets workspace as a dependency of the storybook workspace.

• Create a new script and GitHub action which runs when either package.json or storybook/package.json are modified, checking for any mismatched versions for packages that build the core assets.

It would be good to be clearer about what need to be considered common dependencies as this seems a bit open to interpretation.

Clearly, all the dependencies of the actual plugin JS code are common, and anything related to the build processes that can affect the build output should be as well. Considering how the Webpack config is structured we probably need to say that all Webpack related dependencies need to be kept in sync. I'm not sure if there's anything else that needs to be clarified but the current phrasing is a bit ambiguous, please give it a bit more thought.

It would also be useful to provide a bit more steerage for the implementation of this script, e.g. its location, the GH workflow file name, and any considerations for the GH workflow implementation itself - can we use one of the existing workflows for reference?