-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
The proposal of using monorepo #4353
Comments
I've seen Lerna used at work, and I was not convinced. |
@tommy351 has some exprience on migrating to monorepo. Hopefully he could give us some suggestions. |
I think it will take some time to setup the environment for testing and releasing and the build time on CI will be longer. But it would be great to be able to share configs and utils across the project. |
I wouldn't recommend using lerna nowadays, it's maintenance is seems to fade out and we can get a lot with yarn 3 workspaces alone. |
+1 IMHO, I think it is desirable if we can do it without adding any tools or dependencies. |
I have two questions: |
@tomap, nothing changes on the end users side. We would keep the package hierarchy in NPM registry as it is now. The migration to yarn workspaces and monorepo will affect developers of the packages that became part of the monorepo only. I didn't get the second question, so I assume I miss some context. I allowed myself to chime in this thread because monorepo is a hot topic for me both professionally and personally. I recently migrated a few of my pet projects to yarn workspaces using yarn 3. One of the migration was from rush.js. I don't publish any packages to NPM though. |
Well here is a thing. We just have so many repos to maintain. When we want to fix a bug inside IMHO, this reason alone is already enough for us to migrate to the monorepo approach. |
Sure, so now, plan and then do!
More specific steps? |
I'd like to use yarn workspaces with the latest version of yarn (yarn v3), as pnpm workspaces need Microsoft Rush as its backend while the Lerna is kinda inactive. |
I am monitoring the development of https://turborepo.org/ Maybe we can use the And here is how we should go with:
|
@SukkaW |
Is lerna still necessary now? We can use pnpm / yarn / even npm's native workspaces. @SukkaW If you want, I can do some work under the v7 milestone. |
Sure! That would be awesome! |
So... turborepo and npm? I don't think turbo is necessary either. Hexo is not large and pnpm works well in most scenarios. I prefer using pnpm(personally) |
There are 75 repos under @hexojs org, and at least one-third or half of them will eventually be merged into the monorepo. I believe turbo is a must-have. |
Currently hexo, hexo-util, hexo-cli, hexo-i18n, hexo-fs, hexo-front-matter, hexo-log and warehouse have fully migrated to ts. Do other repositories in monorepo need to be migrated as well? |
IMHO, And if migrating to a monorepo, it would be better to merge the history of each repositories. This is not only beneficial for tracking history but also respects all of contributors to the plugins. I think this can be achieved simply by merging the branch of another repository into the repository we want to merge like below.
|
But that will make the repository's size larger |
Why should we use monorepo?
For example, Hexo is dropping Node.js 8 at this moment. That means every CI config under every repo has to be updated. It is painful.
If we are using monorepo, we could write only one ci config for all packages (run eslint & all unit test cases at once).
Also, with monorepo we could maintain a global
eslintrc
/mocharc
for all packages.What should be included in monorepos
Only for those repos that are not hexo plugins, which means:
hexo-util
,hexo-i18n
,hexo-pagination
,hexo-server
,hexo-cli
, etc. should be merged into monorepos.hexo-renderer-marked
,hexo-filter-nofollow
,hexo-uglify
, etc. should remain separated.When should we start
Right after Hexo 5.0.0 released.
What monorepo manager should we use?
lerna.
Any play ground?
https://github.com/hexojs/hexo-monorepo
@hexojs/core and owners of @hexojs should have access to the repo.
The text was updated successfully, but these errors were encountered: