Closed zaaakher closed 8 months ago
I forgot to remove the commented part, I was going to separate the bullet-points by the categories of the packages but then realized it makes more sense to list them the same way they're grouped in the folders of this monorepo.
Now that I think about it I think it would be better to make them into a table with a badge next to each package that dynamically shows the size and version (same as the badges of each README.md inside each package) I will do that tomorrow inshallah.
@zaaakher this is awesome 🎈! I will put you in the Special thanks section for all your efforts! This is ready to merge from my side. Anything more you want to add?
Thanks @davidjerleke 🥳
I was thinking about a versioning section inspired from your comment here but on second thoughts I think that's something maybe contributors shouldn't touch since you might have a specific approach to putting together PRs and deciding when to publish.
I was thinking about a versioning section inspired from your comment here but on second thoughts I think that's something maybe contributors shouldn't touch since you might have a specific approach to putting together PRs and deciding when to publish.
This is the publishing process for the packages. Running any of these commands below:
...will automatically:
Embla
packages in the entire repository.yarn.lock
file if needed.The publishing part is the only thing that needs manual work. In order to publish I have to manually create a new release on GitHub with the new tag version and hit create release
:
After that the CD process takes over and automatically publishes all packages to the npm
registry if build
, test
and lint
pass.
But at the time of writing, I guess I'm the only one that have the access rights to creating a release.
Best, David
Sounds great 👍
Although I was wondering more about when a contributor should bump a version. So for example if I make a PR fixing a few lines of codes in one of the packages, would you prefer/recommend I bump a patch version in my commit? Or would that disrupt your flow and you could do a bump as well (without noticing my bump) and we end up with one of the packages version not in-sync with the others?
I could be wrong, but you sometimes do 1 bump for multiple PR's you combine, right?
Overall, if you prefer contributors do some versioning in PR's then I think we should include it in the CONTRIBUTING.md
otherwise, we can just leave out the versioning section.
@zaaakher sorry I misunderstood your question:
I could be wrong, but you sometimes do 1 bump for multiple PR's you combine, right?
That's correct. A new version can include multiple bug fixes or features.
Overall, if you prefer contributors include do some versioning in PR's then I think we should include it in the
CONTRIBUTING.md
otherwise, we can just leave out the versioning section.
I would prefer not at this stage but very much appreciate that you ask 🙂!
No worries 😁 ,
In this case I think this PR is complete 👍
@zaaakher great work as always 🥳.
Once again, thanks @davidjerleke for creating this wonderful and promising library ✨
My goal in this PR is to thoroughly detail this project in a way that makes it less intimidating for developers who want to contribute to the inner workings of this project. I will continue adding to it every time I get a chance and I will hopefully learn more about the inner workings of this project as I expand on this contribution guide.
@davidjerleke feel free to throw in a commit every now and then to fix things or add sections or even notes that I can tag-team and expand on.
The good thing about MDX is that if this contribution guide becomes too big we can always move it to
embla-carouse-docs
and break the guide down into multiple sub-pages.