if you're reading this, you are probably interested in contributing to cobalt, which we are very thankful for :3
this document serves as a guide to help you make contributions that we can merge into the cobalt codebase.
currently, we are not accepting translations of cobalt. this is because we are making significant changes to the frontend, and the currently used localization structure is being completely reworked. if this changes, this document will be updated.
before putting in the effort to implement a feature, it's worth considering whether it would be appropriate to add it to cobalt. the cobalt api is built to assist people only with downloading freely accessible content. other functionality, such as:
- downloading paid / not publicly accessible content
- downloading content protected by DRM
- scraping unrelated information & exposing it outside of file metadata
will not be reviewed or merged.
if you plan on adding a feature or support for a service, but are unsure whether it would be appropriate, it's best to open an issue and discuss it beforehand.
when contributing code to cobalt, there are a few guidelines in place to ensure that the code history is readable and comprehensible.
internally, we use a format similar to conventional commits - the first part signifies which part of the code you are changing (the scope), and the second part explains the change. for inspiration on how to write appropriate commit titles, you can take a look at the commit history.
the scope is not strictly defined, you can write whatever you find most fitting for the particular change. suppose you are changing a small part of a more significant part of the codebase. in that case, you can specify both the larger and smaller scopes in the commit message for clarity (e.g., if you were changing something in internal streams, the commit could be something like stream/internal: fix object not being handled properly).
if you think a change deserves further explanation, we encourage you to write a short explanation in the commit message (example), which will save both you and us time having to enquire about the change, and you explaining the reason behind it.
if your contribution has uninformative commit titles, you may be asked to interactively rebase your branch and amend each commit to include a meaningful title.
if your branch is out of date and/or has some merge conflicts with the current branch, you should rebase it instead of merging. this prevents meaningless merge commits from being included in your branch, which would then end up in the cobalt git history.
if you find a mistake or bug in your code before it's merged or reviewed, instead of making a brand new commit to fix it, it would be preferable to amend that specific commit where the mistake was first introduced. this also helps us easily revert a commit if we discover that it introduced a bug or some unwanted behavior.
- if the commit you are fixing is the latest one, you can add your files to staging and then use
git commit --amendto apply the change. - if the commit is somewhere deeper in your branch, you can use
git commit --fixup=HASH, whereHASHis the commit you are fixing.- afterward, you must interactively rebase your branch with
git rebase -i current --autosquash. this will open up an editor, but you don't need to do anything else except save the file and exit.
- afterward, you must interactively rebase your branch with
- once you do either of these things, you will need to do a force push to your branch with
git push --force-with-lease.