Skip to content

Latest commit

 

History

History
143 lines (109 loc) · 5.5 KB

CONTRIBUTING.md

File metadata and controls

143 lines (109 loc) · 5.5 KB
Raw

Contributing

Contributions are welcome! Make sure to first open an issue discussing the problem or the new feature before creating a pull request. This project uses poetry and beet for building and publishing to pypi.

Setup

Make sure you install poetry via the official instructions. Then, setup can proceed like so:

$ git clone https://github.com/Smithed-MC/Libraries
$ cd Libraries
$ poetry install

# To build all projects
$ beet

# To build just one library
$ beet -p smithed_libraries/packs/actionbar
# or
$ cd smithed_libraries/packs/actionbar && beet

Developing

Since we leverage the beet toolchain, there are a couple of useful commands you can use while developing the libraries!

# Links to your .minecraft folder directly into your world
$ beet link "Minecraft World Name"

# Watches all data packs for changes
# Builds then reloads world
$ beet watch --reload

# Watch only on library
$ beet -p smithed_libraries/packs/actionbar watch --reload
# or
$ cd smithed_libraries/packs/actionbar && beet watch --reload

Code Style

The code follows the black code style. Import statements are sorted with isort. The project must type-check with pyright. We recommend running the type-checker via the VSCode Python extension (discussed below).

Format

# omit `poetry run` if u have the virtualenv activated
$ poetry run isort smithed_libraries
$ poetry run black smithed_libraries

Check

# omit `poetry run` if u have the virtualenv activated
$ poetry run black --check smithed_libraries
$ poetry run isort --check-only smithed_libraries

You can run poetry self add 'poethepoet[poetry_plugin]' to get access to an easier set of commands:

# omit `poetry` if u have the virtualenv activated
$ poetry poe format
$ poetry poe check

IDE

We recommend using VSCode. The following recommendations are made based on if you are making minecraft pack and/or python contributions.

Minecraft

We recommend using the Bolt Syntax Definition (This links to the Beet Discord Server - Github coming soon). This extension is compatible with normal mcfunction commands while also allowing for multiline and bolt support.

You can use DHP / Spyglass for most of the libraries as currently, only some libraries use bolt extensively.

Python

We recommend using the official Python extension. This extension comes with type-checking support alongside automatic formatting and import sorting via the settings (coming soon).

Commits

When committing code, follow the Conventional Commit style for writing commit messages:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Examples

  • feat(damage): added new apply function
  • docs(actionbar): add usage information to API functions
  • fix(*): versioning hiccup in rare situations
  • feat(plugins): add new nbt-literals plugin for packs to use

Note

Here are the types and scopes we'll be using (adapted from here):

Types

type [version]: description

  • feat [minor]: A new feature
  • fix [patch]: A bug fix
  • perf [patch]: A code change that improves performance
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • test: Adding missing or correcting existing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

Scopes

name (type): description?

  • * (special): bumps every library
  • actionbar (lib)
  • crafter (lib)
  • crafter-addon (lib)
  • damage (lib)
  • enchanter (lib)
  • item (lib)
  • prevent-aggression (lib)
  • plugins (beet): custom plugins that power smithed

Extras

  • The start of can be BREAKING CHANGE to indicate a major version bump
  • Keep each line under 100 characters

Versioning

Each library pack has their own version as well as the entire repo itself. When producing new releases, you'll need to ensure you properly bump the versions for the libraries you've edited.

These can be found in the following files:

  • packs/<pack-name>/beet.yaml -> version field
    • only bump this only for specific library
  • pyproject.toml -> tool.poetry.version field
    • automatically bumped when release is made or "Release PYPI" workflow is ran

We follow the semantic versioning format for versioning:

  • major reserved for breaking changes (needs maintainer approval)
  • minor for new features and larger tweaks (usually changing user experience like updating crafter recipe)
  • patch for bug fixes and smaller tweaks (usually doesn't affect user experience)

The commit guide provides a table of contents to indicate whether a bump should be patch or minor.

Releasing

Making a new release happens automatically once you've bumped the version number of a specific library (or multiple).