checklist-when-doing-Forge-PRs.md

Forge PRs can be quite tricky to understand and get working but if you can get your new event or hook or fix into Forge, you benefit a ton of modders! Don't let the idea of a Forge PR scare you or seem too daunting! Just follow this gist and hopefully you'll get the hang of it!

The first step is check out gigaherz's gist for creating a PR:
https://gist.github.com/gigaherz/ca256fea517cb925dfc31d7cd48c487e

Forge's doc on making PRs with extra into and styling rules:
https://github.com/MinecraftForge/MinecraftForge/wiki/If-you-want-to-contribute-to-Forge

Things to keep in mind:

Though there are several notes to keep in mind as you make the PR. This gist serves to be like a nice checklist to glance over after you got your PR nearly ready after following the above links. Do note, these notes are split up into two parts because best practices for the code you put in the Forge codebase may not be the same best practice for the PR's patch code being put into the vanilla codebase.

Also, do not mention any other modloader besides Forge and do not mention coremods in any form (example: saying this PR is needed because x mod is coremodding due to lack of a hook. Saying that will get your PR closed and denied)

Forge Side Notes:

• Do not edit in the forge/clean subproject, only edit forge/main. If you edit forge/clean, everything blows up!

• All new files need license headers added. Run checkLicenses task to see if there is any file that is missing license headers. If so, then run updateLicenses task to scan all files and automatically add the Forge license headers to them.

• Spaces around the outside of parentheses () in if/while/for/switch statements such as if (someBool) instead of if(someBool).

• Braces belong on new lines, if statements that are a single line do not need braces, and switch statement's cases are indented.

• Always use spaces instead of tabs. Check your IDE settings as some may try to convert spaces to tabs which will cause GitHub to mess up the formatting as it displays tabs weirdly.

Patch Side Notes:

• Try to keep your patch's changes to Minecraft's code as small as possible. By this, they mean keeping the diff in code itself minimal. So make if statements with a single line of code inside be entirely on a single line if possible. And no extra blank lines as well around the if statement. More info about this is here:
  https://github.com/MinecraftForge/MinecraftForge/wiki/If-you-want-to-contribute-to-Forge#conventions-for-coding-patches-for-a-minecraft-class-javapatch

• Do not remove, add, or modify any existing import in a patch. Double check your IDE's settings and make sure it won't auto-create wildcard * imports or re-organize/delete imports. If you need to use a class outside the patch, use fully qualified names. This means to use Forge's BlockSnapshot class in a patch, do net.minecraftforge.common.util.BlockSnapshot to avoid needing to add an import.

• If you add ATs (AccessTransformers) as part of your PR, run checkATs task. Then run the setup task. If the AT still doesn't apply for whatever reason, run the clean task and then run setup task again.

• If you need to de-OnlyIn a thing, add it to forge.sas and run checkSAS task. (SAS stands for Side Annotation Stripper)

• When you believe your PR looks good, run gradlew build checkPatches checkATs checkSAS publish to have all those tasks look over your PR's code and point out if anything is wrong.

If you are unsure how to best format your patch to keep it as small as possible while also maintaining readability, you can ask for advice in #issues-and-prs channel of Forge's official discord. But ultimately, they will tell you if your formatting needs to be adjusted as part of the PR review process later on anyway.

How to make a test mod in the PR:

Creating a test mod for your PR significantly raises the chances of it being merged or reviewed as it is now less work for the Forge team. Here's how to slap in a test mod:

• Create the test mod's constructor class in src/test/java/net/minecraftforge/debug/<folder>. <folder> will be the folder that your PR best fits in but you can make a new folder instead if none of the existing ones fits your PR. Typically, the test mod class is usually named <event name>Test such as BiomeLoadingEventTest to make it clear as to what it is testing.

• If your test mod requires some assets or data files to work, put those in src/test/resources's assets/data folder under your test mod's modid.

• Now go to the src/test/resources/META-INF/mods.toml file and add your modid to it to tell Forge it exists and can be ran.

[[mods]]
    modId="test_mod_id_goes_here"

• Follow this Forge doc to run your test mod to make sure that it works and that your PR also works properly:
  https://mcforge.readthedocs.io/en/latest/forgedev/#enabling-test-mods
  Note: If you are trying to test on servers in dev and you find it is crashing because of other people's client-side test mods, you can temporarily disable those test mods by removing them from the mods.toml and then run your serverside testing (make sure you add them back after you are done testing your test mod)

How to make sure triage sees your PR is ready for review:

Once your PR is ready and finished and you uploaded it to the Forge PR section, now you need to get the Triage label so that the triage team can review it later. Make a reply to your PR that tags @Minecraftforge/issuemanager and say that your PR is ready for review and merging. If you want to make extra sure that your PR will not get forgotten, you can go to the #issues-and-prs channel in the official Forge Discord and (without pinging anyone), ask for the triage label to be put on your PR. The Forge Discord is here: https://discord.gg/UvedJ9m