Development walkthrough in CONTRIBUTING.md

[zaaakher]

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.

[zaaakher]

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.

[davidjerleke]

@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?

[zaaakher]

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.

[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.

This is the publishing process for the packages. Running any of these commands below:

embla-carousel/package.json

Lines 51 to 53 in 0103684

	"version:patch": "yarn workspaces foreach version patch && yarn version:push",
	"version:minor": "yarn workspaces foreach version minor && yarn version:push",
	"version:major": "yarn workspaces foreach version major && yarn version:push",

...will automatically:

• Bump the versions of all Embla packages in the entire repository.
• Update the yarn.lock file if needed.
• Add all file changes and a new tag with the new version to git.
• Push the tag and commit to the remote repository.

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:

embla-carousel/.github/workflows/cd.yml

Lines 3 to 6 in 13d195d

	on:
	release:
	types: [created]

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

[zaaakher]

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.

[davidjerleke]

@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 🙂!

[zaaakher]

No worries 😁 ,

In this case I think this PR is complete 👍

[davidjerleke]

@zaaakher great work as always 🥳.