Loader: Intro, fabric.mod.json, Dependency Overrides

[cassiancc]

Updated and revised ports of the Fabric Loader and fabric.mod.json, and Dependency Overrides pages from the wiki. I've opted not to include the more technical aspects of the Fabric Loader article, as I do not consider them relevant to the Docs and cannot speak to their accuracy, but that can be added back later if desired.

[netlify]

✅ Deploy Preview for nimble-elf-d9d491 ready!

Name	Link
🔨 Latest commit	0c71df5
🔍 Latest deploy log	https://app.netlify.com/projects/nimble-elf-d9d491/deploys/69e6a6c46ec343000808c89a
😎 Deploy Preview	https://deploy-preview-557--nimble-elf-d9d491.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[modmuss50]

Looks great, just a few things I noticed. Feel free to skip some of them if you think its out of scope for this PR.

[its-miroma]

sorry, I couldn't even finish reviewing one file, but I'll start with these

[its-miroma]

These files are looooooong

[Poopooracoocoo]

Why is the page on dependency overrides in the developer section? Developers won't be touching that. Players will.

[cassiancc]

I consider it a modpack developer tool - it could honestly go in either section, but I agree having it in players might be more correct.

[its-miroma]

It seems that many examples you provided mostly don't match with the Semver checker. For example: >26 <26.2 does NOT match 26.1 on there. Either the Fabric checker works differently, so the checker is irrelevant, or the examples are inaccurate.

---

I have a question: does the range 26.1 match 26.1.2? Because jubianchi's checker interprets 26.1 as 26.1.*, which means it matches 26.1.2.

Also: does Fabric understand that 26.1.0 should mean Tiny Takeover?

---

Please add this at the top of the file:

<script setup lang="ts">
import { h } from "vue";

const Range = ({ r }) => h(
  "a", 
  { 
    href: `https://jubianchi.github.io/semver-check/#/${encodeURIComponent(r)}/26.1.2`,
    target: "_blank",
    rel: "noreferrer",
  }, 
  h("code", r)
);
</script>

then:

Suggested change

	1. To depend on any version of the dependency, just write `*`.
	2. To depend on only a specific version of the dependency, just write its version number, e.g. `26.1`.
	3. To depend on all versions of the dependency above a version, write `>26`.
	4. For a more complicated dependency, like a dependency on Minecraft 26.1 and its hotfix, 26.1.1, we could use any of the following examples:
	::: details Examples for a dependency on 26.1 and 26.1.1
	- `[26.1, 26.1.1]` - Will only load on 26.1 and 26.1.1, none of their snapshots, pre-releases, release candidates, or the April Fools version 26w14a (parsed by Fabric as `26.1.1-alpha.26.14.a`).
	- `>26 <26.2` - [Will load on all versions higher than 26 and lower than 26.2](https://jubianchi.github.io/semver-check/#/%3E26%20%3C26.2/26.1.0), including all snapshots, pre-releases, release candidates, but also the nonexistent 26.0 versions.
	- `>=26.1 <26.2` - [Will load on all versions greater than or equal to than 26.1 and lower than 26.2](https://jubianchi.github.io/semver-check/#/%3E26%20%3C26.2/26.1.0), including 26.1 and any hotfixes for it, as well as snapshots, pre-releases, release candidates for these hotfixes..
	- `26.1.x` - [Will load on any 26.1.x version](https://jubianchi.github.io/semver-check/#/26.1.x/26.1), including snapshots, pre-releases, and release candidates for 26.1 and 26.1.1.
	- `~26.1` - [Will load on any 26.1.x version](https://jubianchi.github.io/semver-check/#/~26.1/26.1), including snapshots, pre-releases, and release candidates for 26.1 and 26.1.1.
	- `^26.1` - [Will load on any 26.x.x version](https://jubianchi.github.io/semver-check/#/^26.1/26.1), including snapshots, pre-releases, and release candidates for 26.1, 26.2, and above, but not including 27.x.
	Here are some examples of ranges and what they indicate. Try using [jubianchi's Semver check](https://jubianchi.github.io/semver-check/#/) to test which values will satisfy the constraint.
	| Range | Description | Matches | Clashes |
	| ----- | ----------- | ------- | ------- |
	| <Range r="*" /> | Any version (not recommended) | `26.1.2`, `24w14potato`... | _none_ |
	| <Range r="26.1.2" /> | Exact version only | `26.1.2` | `26.1`, `26.1.1`, `26.2`... |
	| <Range r="26.1.0 \|\| 26.1.1" /> | Either range | `26.1.0`, `26.1.1` | `26.1.2`, `26.2`... |
	| <Range r="[26.1.0, 26.1.1]" /> | Equivalent to `26.1.0 \|\| 26.1.1` | `26.1`, `26.1.1` | `26.1.2`, `26.2`... |
	| <Range r=">26" /> | Above a version (exclusive) | `26.1.2`, `26.2`... | `26`, `25.x`... |
	| <Range r=">=26.1" /> | At or above a version (inclusive) | `26.1`, `26.1.2`, `26.2`... | `26.0`, `25.x`... |
	| <Range r="<=26.1" /> | At or below a version (inclusive) | `26.1`, `26.0`, `25.x`... | `26.1.2`, `26.2`... |
	| <Range r=">26 <26.2" /> | Between two versions (both exclusive) | `26.1`, `26.1.2`, snapshots... | `26`, `26.2`... |
	| <Range r=">=26.1 <26.2" /> | Between two versions (inclusive lower bound) | `26.1`, `26.1.2`, snapshots... | `26.0`, `26.2`... |
	| <Range r="26.1.x" /> | Any patch of a minor version | `26.1`, `26.1.2`, snapshots... | `26.2`, `27.x`... |
	| <Range r="~26.1" /> | Same as `26.1.x` | `26.1`, `26.1.2`, snapshots... | `26.2`, `27.x`... |
	| <Range r="^26.1" /> | Any version in the same major | `26.1.2`, `26.2`, `26.3`... | `25.x`, `27.x`... |

Note: Prettier will flag this because the columns will not be padded properly. Sorry!

Also: maybe it'd be cleaner if this were a global component in .vitepress/theme/components/Range.vue; I'll probably fix that after this review is implemented.

[cassiancc]

Providing a dependency range of 26.1 would fail on 26.1.2 as I believe Fabric converts it to 26.1.0, this would be a difference from the semver checker.

[its-miroma]

Ah, that makes sense! This means Fabric's version checker is not compatible with Node.js'. I'm not saying it needs to be, but let's mention that 26.1 means 26.1.0

[its-miroma]

I haven't fully reviewed this file yet, but I don't want to impede this PR further. I think we can merge this, then tackle it at a later date