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

Core: Consolidate internal packages #25751

Closed
wants to merge 33 commits into from
Closed

Conversation

ndelangen
Copy link
Member

@ndelangen ndelangen commented Jan 25, 2024

What I did

  • I've moved source of most of the packages in code/lib into code/core/main.
  • I've removed references to these packages in the monorepo with a reference to @storybook/core
  • I've added @storybook/core as a devDependency and peerDependency to all packages previously referencing.
  • I've created significant complex bundling code for @storybook/core
  • I contains an entrypoint for every package that was consolidated, to preverse backwards compatibility.
  • Due to the amount of exports, I generate the exportsmap in package.json

Learnings:

  • Cyclical dependencies are hell, it's very easy to get trapped in a X needs core, core needs Y, Y needs Z, and Z needs core, due to how much code is in core.
  • A lot of code is actually agnostic if it runs in node or browser.
  • TSup silently skips files/entrypoints it cannot find.
  • The output path of TSup can be really confusing, it's dependent on the shared file-tree of all entrypoints.
  • process, util, assert and other node-friends have an tendency to show up in browser bundles.
  • It's extremely important for the final bundler (preview,manager) to be consuming the ESM version of the dist.
  • Getting the peerDeps right is hard. I'm still unsure if I have peerDeps for things such as react correctly in this spike.
  • It's very easy to get in a situation where you end up with the same code bundled twice, in fact it's possible/likely that's currently the case in this spike.

TODO:

  • support for creating a production-build of @storybook/core
  • generating *.d.ts files for entrypoints that matter (and only those that matter)
  • support for compiling @storybook/core in watch mode. I have some thoughts on this.. the watch-mode os esbuild is not good enough, and consumes a lot of memory. With this many entrypoints & side-effects, it might be better to implement our own using chokidar + https://esbuild.github.io/api/#rebuild
  • testing backwards compatibility
    • does importing @storybook/theming in a manager entry work?
    • does importing @storybook/preview-api in preview entry work?
  • migration documentation for addon creators
  • auto-migrations for users
    • they should get their imports changed in their manager & preview entries
    • they should get their dependencies in package.json changed.
  • The core bundle script should maybe have some sort of 'development' mode, where it skips on compiling the entrypoints that will never get used within the confines of the monorepo (they are there for backwards compatibility. (I do not yet know what subset that really is).
  • the deprecated packages should be changed, to not need a compilation step anymore (similar to how the code/lib/sb package doesn't need anything. Neither their source, nor their dist, will ever change again.

Checklist for Contributors

Manual testing

I was able to generate a sandbox (vite-react-ts) and run it with linking.
I was able to navigate to different stories, including docs pages, and it all looked fine.

I have not taken any further steps to actually test anything else.

  • test-runner
  • webpack based sandboxes
  • angular
  • yarn pnp
  • testing with community addons

Documentation

As listed in the TODO section, this will need a big section in the migration documentation.

Though it's likely preferable to update the documentation to something else at some point in the future... imports like: @storybook/core/dist/modules/preview-api/index is NOT the final API, so it's not recommended we actually update the docs to reflect that yet? This needs to be debated amongst the team.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

Copy link
Contributor

github-actions bot commented Feb 13, 2024

Fails
🚫 PR is marked with "ci: do not merge" label.
🚫

PR is not labeled with one of: ["cleanup","BREAKING CHANGE","feature request","bug","documentation","maintenance","build","dependencies"]

Generated by 🚫 dangerJS against 31c3732

Copy link

socket-security bot commented Feb 13, 2024

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package New capabilities Transitives Size Publisher
npm/@storybook/[email protected] Transitive: environment, eval, filesystem, network, shell, unsafe +47742 5.87 GB shilman
npm/@types/[email protected] None +1 70.1 kB types
npm/[email protected] environment, network 0 140 kB lpinca

🚮 Removed packages: npm/@storybook/[email protected]

View full report↗︎

Copy link

socket-security bot commented Feb 13, 2024

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert Package NoteSource
New author npm/[email protected]
Uses eval npm/@storybook/[email protected]
Uses eval npm/@storybook/[email protected]
Uses eval npm/@storybook/[email protected]
Uses eval npm/[email protected]
Uses eval npm/@storybook/[email protected]
New author npm/[email protected]
Uses eval npm/@storybook/[email protected]
Uses eval npm/[email protected]
Shell access npm/[email protected]

View full report↗︎

Next steps

What is new author?

A new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.

Scrutinize new collaborator additions to packages because they now have the ability to publish code into your dependency tree. Packages should avoid frequent or unnecessary additions or changes to publishing rights.

What is eval?

Package uses eval() which is a dangerous function. This prevents the code from running in certain environments and increases the risk that the code may contain exploits or malicious behavior.

Avoid packages that use eval, since this could potentially execute any code.

What is shell access?

This module accesses the system shell. Accessing the system shell increases the risk of executing arbitrary code.

Packages should avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced.

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/[email protected] or ignore all packages with @SocketSecurity ignore-all

@ndelangen ndelangen closed this Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant