I noticed that the compiled JAR (0.8.1 on Curseforge) has Fabric API parts embedded in it, in the META-INF and the manifest:

  "jars": [
    {
      "file": "META-INF/jars/fabric-api-base-0.3.0+a02b446318.jar"
    },
    {
      "file": "META-INF/jars/fabric-resource-loader-v0-0.4.8+a00e834b18.jar"
    },
    {
      "file": "META-INF/jars/fabric-command-api-v1-1.1.3+5ab9934c18.jar"
    }
  ]

Because Fabric API is being used by about 99% of Fabric users and it gets updates often anyway, could you please remove it from the compiled JAR to reduce file size and improve futureproofing?
Notably it doesn't exist in the manifest uploaded here, so I don't really know how this bundling works.

I'm reconsidering this decision. Still no conclusive answer but I wanted to reopen the issue.

Can you elaborate on this though?

there are some specific scenarios where I need to have certain parts of the api without it being installed

Both in some runtime testing scenarios and with a limited mod set I have in some places I do not want features such as /citresewn or fapi's resourceloader api to not be available.

Also considering bundling those two modules and the api base only adds ~69KB(nice) I think it's a fair trade for the convenience of not having to explain why certain parts are dependent on fapi when CIT Resewn does not need to use 99% of the api.

Okay, fair enough.

While I understand fabric api is used almost everywhere, there are some specific scenarios where I need to have certain parts of the api without it being installed.

There's no need to future proof because a dedicated fabric api jar/later version of fapi will always have priority over bundled jars.

I'd understand the request if it added a lot but fabric api is built specifically in a way that allows bundling a few parts without bundling the entire api(specifically command api and resource loader in this case). CIT Resewn with these parts of fapi as of v0.8.1 is only 266KB which is barely anything when it comes to file sizes and download speeds by today's standards.

To answer your question on how they are bundled, Fabric's Loom does this automatically for me because I specified include on those jars.

While there are some edge cases where I do think bundling parts of fapi would be beneficial, I decided against it.

My "up to date statement" on the matter(for future reference) is that Fabric API, while still being developed separately from the loader, should always be in all fabric environments.

Starting with v0.8.2, CIT Resewn will support that statement.
I'm making it depend on Fabric API completely(as in, crash when not present).