-
Notifications
You must be signed in to change notification settings - Fork 6.2k
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
Consider Transforming this into a Monorepo after the initial Website Redesing is done #5405
Comments
What about turborepo or nx those are also phenomenal choices for monorepo |
We do use turborepo :) |
This comment was marked as outdated.
This comment was marked as outdated.
@Harkunwar, I guess it would make sense to start investigating the Monorepo approach. Things to keep in consideration:
Possible green flags:
Since on the infrastructure side of things, things look good enough, and the work we have now is for migrating components (at the moment), it might be a good bet of migrating this to a monorepo. |
@ovflowd Sounds good to me! I'll start investigating migrating to monorepo. |
This comment was marked as outdated.
This comment was marked as outdated.
Here my 2 cents: NX preach that the project should have 1 package.json, and versions should be the same for all projects. The tradeoff is when you have 2 or 3 Apps, and a Storybook, you will always download the app dependencies with storybook as well. In the case you use npm install --prod, should be a better way to use on CI. Turborepo allows you to have many package.json for projects. It can be good or bad haha. I have been using Turborepo in the company i work, for mantain 4 apps, and some components library. But also i use NX in other repository, because it already have the bundler with near zero configuration. That's a good approach for TS / JS Packages. We use this for service layer and analytics. We have a good point to use NX for our storybook library. In summary, Turborepo is good for Many Apps, and components library. ChatGPT correct my poor english: When it comes to project management practices, NX advocates for a single package.json file and consistent versioning across all projects. However, there's a notable consideration to keep in mind. In scenarios where you're dealing with multiple applications (2 or 3) alongside a Storybook, a potential tradeoff arises. When you perform an npm install --prod, the app dependencies and Storybook are downloaded together. To address this, finding a more efficient way to use it within a Continuous Integration (CI) context becomes important. This is where Turborepo comes into play. It offers the flexibility of employing multiple package.json files for different projects. The outcome can be positive or negative, leading to a mix of experiences (which can be quite amusing!). Personally, I've leveraged Turborepo within my company, managing four applications and a components library. On the flip side, for separate cases, I've utilized NX in other repositories. The reason being, NX provides an almost effortless configuration for bundling, especially ideal for TypeScript (TS) and JavaScript (JS) packages. This approach works remarkably well for our service layer and analytics needs. Additionally, NX shines as a great choice for managing our Storybook library effectively. In a nutshell, Turborepo proves its worth when dealing with numerous applications and a components library. On the contrary, NX emerges as the preferable option for streamlining packaging and maintaining consistent libraries across the board. |
Looks cool. Except that Note: With publish I mean locally within the monorepo, we're not going to publish these on NPM. |
Hey @alexcastrodev I appreciate your input here. We're very probably sticking with Turborepo as it is what makes sense here. Mostly because we rely on Next.js; I never heard about For example, tie i18n package will only at most have a bunch of JSON files, the ui-components will have just pure React Components. |
I don't understand this part. Not the sentences I mean the code logic behind. some question to advance on this issue
|
Hm? Could you explain?
Yes. The UI Component Library needs to be transpiled (TypeScript -> JavaScript) and then minified for Production usage. It also needs to be Framework agnostic (e.g.: Not Next.js nor React dependent) so it will use plain JSX as a target. |
You say "publish" but also "not publish to npm". So what do you mean by publish |
Pretty much "publish" on the repository, through git tags and GitHub release feature :) |
I think we'll be able to do this issue after the Redesign is online. |
👋 Here from Turborepo team. Happy to help as needed! |
Any help is appreciated! Feel free to join our Slack if you'd like to coordinate this! |
@ovflowd I'm seeing two active Slack servers on the Get Involved page. Do you have a recommendation for which one to hop into and a channel(s) to offer up support in? |
@anthonyshew this link is normally valid |
Node Slackers is not an official community maintained by the Foundation, so only the Foundation Slack matters |
Thanks, both of you! Will join the party. |
@anthonyshew how can we get this started? :) would love to start coordinating efforts to make the monorepo as described on the opening issue possible! |
Hey @anthonyshew any progress? Is there anything we can help you to get started? |
@ovflowd Hey, sorry for not seeing these pings! My GitHub notifications are...effectively useless. 😄 Catching up with the conversation here, it looks like I'm in general agreement with the approach described (with some slight tweaks). Before I write out what my recommendations would be, a couple questions:
None of this is to say that I'm against converting to a multi-package workspace. I'm moreso making sure we did our homework before making this change. 😄 So, assuming we continue towards a monorepo, a few things that I'd be recommending:
There's a lot more to how that migration works but I've likely already written too much here so I'll take a breath to let others respond. 😄 |
pnpm has been discussed but there is a bit of concern about contributor approachability #5334 yes we all know about corepack, but we REALLY care about limiting tooling, even with how easy
Agree some of the breakdown in the OP looks like directories, without any clear reasoning as to why a discrete versioned/published package is necessary. To be fair, the OP content is now quite dated and might not reflect the state of our goals or the tech. This is largely in support of helping the api docs get a facelift. IIRC, the goal is to extract the styles out into a pacakge so we can import them into the main nodejs/node project. how we do that is not yet resolved. |
Yes, all the UI components are one because we want to be able to use these UI components in other repositories. Is a publish needed? I assume we can reference the package through NPM's git resolution algorithm? i.e., "nodejs/web-components": "git://github.com/nodejs/nodejs.org/packages/...." (Not even sure this would work as expected)
This repository? No.
We want to simplify CI processes and decouple dependencies to make build, testing, rollbacking, and maintenance easier. We also want to be able to use certain packages outside of the nodejs.org repository in other projects and packages.
I'd recommend that everything is NPM compatible and recommended by default, but our CI could use PNPM. We would still recommend NPM as the default method for newcomers, but we can use PNPM within our CI to speed up CI build, processes, etc.
Solid point. |
If no versioning is needed besides of just Git commit versioning, I'm fine with it :) Since most of packages would be consumed internally and not by outer parties/community. |
Heard to both of you! It sounds like there's been much more thought put to making this move than I'm aware of or could find. Awesome! I'm still unclear on the publishing story - but sorting that out can be done after creating the multi-package workspace's structure. Thinking about migrating now, does this plan sound like the approach we'd like to take?
|
If we can fulfil what we need without publishing, I'm down for it :) |
Sound like a solid plan! |
BTW, I'm working on creating the package that compiles the MDX so that the code can be shared between different apps (nodejs.org, ?undici.nodejs.org). |
Hmmmm, sure. But... we don't have any out-of-the-world MDX compilation. We use standard MDX compilation pretty much, so I'm not sure another package is needed, to be honest. |
I've opened the door. You can go and see. But what I take from it is that it could potentially be simpler to use MDX-remote. Ressource about using mdx-remote: |
After we get the Website Redesign done, we might want to change to a Monorepo structure, which could quickly offload which parts of the Website need to be built due to what is being changed. This should be considered only after we successfully completed #5403.
What is this about?
How would the Monorepo be structured
packages/i18n
(versioned)packages/ui-components
(versioned)components
components
packages/core
(Name subject to change) (versioned)apps/nodejs-website
cc @nodejs/website as I'd love to get opinions on this matter from y'all :)
The text was updated successfully, but these errors were encountered: