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

feat: hello, monorepo! #7736

Merged
merged 22 commits into from
May 13, 2024
Merged

feat: hello, monorepo! #7736

merged 22 commits into from
May 13, 2024

Conversation

tkajtoch
Copy link
Member

@tkajtoch tkajtoch commented May 6, 2024

Summary

This PR moves all EUI source files to packages/eui (including src-docs) and enables yarn workspaces to link local versions of all EUI packages - which is currently one 🤣

I recommend reviewing commit per commit due to Github's inefficiency in rendering lots of file moves.

The goal of this change is to allow the separation of EUI components into their own small packages in the (near) future. This has many benefits like independent versioning possibility, increased performance and developer experience, separation of concerns, and more.

QA

This PR should be reviewed as a major dependency upgrade due to the possibility of affecting dependency resolution.

  1. Checkout this branch locally and cd into packages/eui
  2. Run yarn build and ensure EUI builds with no errors
  3. Run yarn test-unit and yarn test-cypress and ensure EUI passes all tests
  4. Run yarn lint and ensure all lining tools work and the code passes tests
  5. Run yarn start, wait for it to build, visit http://localhost:8030 and test the docs site works as expected

General checklist

  • Browser QA
    • Checked in both light and dark modes
    • Checked in mobile
    • Checked in Chrome, Safari, Edge, and Firefox
  • Docs site QA
  • Code quality checklist

@tkajtoch tkajtoch self-assigned this May 6, 2024
@tkajtoch tkajtoch marked this pull request as ready for review May 6, 2024 18:03
@tkajtoch tkajtoch requested a review from a team as a code owner May 6, 2024 18:03
@JasonStoltz
Copy link
Member

We should update https://github.com/elastic/eui/blob/main/wiki/contributing-to-eui/running-eui-locally.md to indicate at the top that everything is relative to the package/eui directory. Otherwise, folks will likely try to run yarn start from the project root.

package.json Outdated
"version": "1.0.0",
"description": "Elastic Design System",
"scripts": {
"pre-push": "yarn --cwd packages/eui pre-push"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain why pre-push is kept at the project root?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way pre-push npm dependencies work is they replace the original (usually empty) .git/hooks/pre-push file with their script calling a Node.js script handling executing scripts defined in package.json and similar. There's one gotcha with this behavior - if a monorepo has multiple of these pre-push "managers" configured to initialize on yarn install, they'll override each other. That's why I opted for a single, root-defined pre-push library that will call child packages (like packages/eui or packages/website) instead.

@@ -0,0 +1,19 @@
{
"name": "@elastic/eui-monorepo",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also explain why yarn.lock needs to be at the root level?

It would seem to me that it must be at the same level as the package.json file. Otherwise, I don't understand how packages are properly kept isolated from one another. Theoretically, different packages could have different versions of different dependencies, and wouldn't a single yarn.lock file mess that up?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I read all dependencies are hoisted to the root level and yarn workspaces requires a single yarn.lock at the root, does that sound correct?

Copy link
Member Author

@tkajtoch tkajtoch May 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's correct! There can be only one yarn.lock per project, and our project is now defined by the root-level private package. Yarn uses hoisting to store the dependencies at the root level and reuse them for all packages within the whole monorepo (assuming the semver of these packages matches).

There's a way to opt-out from this hoisting behavior in case of dependencies that specifically require being stored at the correct node_modules directory, e.g., eslint-plugin-local (it cannot resolve the correct .eslintplugin.js when stored in the root node_modules dir) or stylelint (it cannot resolve customSyntax dependencies).

yarn.lock Outdated
resolved "https://registry.yarnpkg.com/react-focus-lock/-/react-focus-lock-2.9.5.tgz#8a82f4f0128cccc27b9e77a4472e8a22f1b52189"
integrity sha512-h6vrdgUbsH2HeD5I7I3Cx1PPrmwGuKYICS+kB9m+32X/9xHRrAbxgvaBpG7BFBN9h3tO+C3qX1QAVESmi4CiIA==
react-focus-lock@^2.9.4, react-focus-lock@^2.9.5:
version "2.12.1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you intend to update these version in yarn.lock?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was updated when I corrected the resolutions field by moving it back to the root-level package.json. I realized it doesn't work when defined at package level (e.g., packages/eui).

The commit message of 14af611 explains that :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I didn't really gather that from the commit message. So it is OK that our yarn.lock file is updating from the current version of 2.9.5 to 2.12.1?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You were right, this minor version bump caused that cypress test to fail. I fixed it in 03f8dc9

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ 🔗 This Snyk upgrade PR is related to this issue

@JasonStoltz
Copy link
Member

Have you tested the publishing process yet?

JasonStoltz

This comment was marked as resolved.

@tkajtoch

This comment was marked as resolved.

@JasonStoltz

This comment was marked as resolved.

@JasonStoltz

This comment was marked as resolved.

@JasonStoltz

This comment was marked as resolved.

Copy link
Member

@JasonStoltz JasonStoltz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like everything is working well so this LGTM. Any idea why we have failing tests? Not sure if it could be related to the react-focus-on update?

1) Cell focus utils
--
  | correctly toggles the header cell actions on focus when tabbing back into the datagrid:
  |  
  | Timed out retrying after 4000ms
  | + expected - actual
  |  
  | -'dataGridKeyboardShortcutsButton'
  | +'dataGridHeaderCellActionButton-column'
  |  
  | at assertFocusedHeaderActions (webpack://@elastic/eui/./src/components/datagrid/body/cell/focus_utils.spec.tsx:195:19)
  | at Context.<anonymous> (webpack://@elastic/eui/./src/components/datagrid/body/cell/focus_utils.spec.tsx:222:4)

Copy link
Member

@JasonStoltz JasonStoltz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually going to remove my approvals until we get the failing specs figured out

@tkajtoch
Copy link
Member Author

tkajtoch commented May 8, 2024

@JasonStoltz I updated running-eui-locally.md to cover the monorepo changes

@tkajtoch tkajtoch requested a review from JasonStoltz May 10, 2024 10:59
"pre-push": "yarn --cwd packages/eui pre-push"
"pre-push": "yarn --cwd packages/eui pre-push",
"preinstall": "echo \"\\x1b[K\\x1b[37;41mWarning: EUI has recently migrated to a monorepo structure. Please run EUI scripts like \\x1b[1;4myarn start\\x1b[0m\\x1b[37;41m or \\x1b[1;4myarn build\\x1b[0m\\x1b[37;41m from the \\x1b[1;4mpackages/eui\\x1b[0m\\x1b[37;41m directory instead!\n\nIf this is the first time you're running EUI after the monorepo migration, please run this first from the root repository's directory to clean up your local environment:\n \\x1b[1;4mrm -rf node_modules .cache-loader dist es lib optimize test-env types .eslintcache eui.d.ts && yarn\\x1b[0m\\x1b[37;41m\n\nInstall process will continue in 10 seconds...\\x1b[0m\"; sleep 10",
"start": "echo '\\x1b[K\\x1b[37;41mPlease run this script from the \\x1b[1;4mpackages/eui\\x1b[0m\\x1b[37;41m directory instead\\x1b[0m'; exit 1",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really nice thinking to add a warning here 🎉 Worked like a charm and caught me doing silly things! 🐟

@mgadewoll
Copy link
Contributor

Awesome work on the monorepo setup! 🎉
I ran the PR locally and everything seems to work as expected:

  • builds run and built outputs can be served and run as expected
  • all unit and cypress tests pass
  • linting runs as expected and passed
  • the local development environments build and run as expected (Storybook and EUI docs)

Copy link
Member

@JasonStoltz JasonStoltz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kibanamachine
Copy link

Preview staging links for this PR:

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

History

cc @tkajtoch

@tkajtoch tkajtoch merged commit 5c40315 into elastic:main May 13, 2024
5 checks passed
@mgadewoll mgadewoll mentioned this pull request May 27, 2024
11 tasks
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.

5 participants