Hi @ZachHandley. This is an intentional decision. In Masto.js, we by design provide more tolerant types for parameters and more strict types for return values, and this applies to all other APIs in this project.

We believe this boosts developer experience by allowing developers to pass an immutable type as an argument, which is frequently used in libraries that adopt the functional paradigm.

// Both are allowed, but later one would cause a compile error without `readonly`
masto.v1.accounts.relationships.fetch({ id: ["123", "456", "789"] })
masto.v1.accounts.relationships.fetch({ id: Object.freeze(["123", "456", "789"]) });

However, as you pointed out, this could hinder those who would like to use Masto.js parameter types to annotate a mutable object before passing them as an argument. I still believe readonly would be worth this drawback, but if you really need the intermediate state of arguments, I would recommend you using some utility type like below:

type Mutable<T> = {
  -readonly [P in keyof T]: T[P];
};

const params: Mutable<mastodon.rest.v1.CreateMediaAttachmentParams> = {
  file: new File([""], "filename"),
}

params.description = "description";
params.focus = "0.5,0.5";

rest.v1.media.create(params);

So in a use-case like mine, I have server-side code that fetches the media, and if there's a thumbnail there then it fetches that as well, as this requires blobs. I guess I don't quite understand how you would normally go about the flow for creating? If you are looking at a server-environment, the only possible way to get the data there otherwise would be form-data, no?

I'm not sure what your use case is, but sounds like readonly seems irrelevant here. Masto.js is just a lightweight wrapper around Mastodon's REST API, so please refer to their documentation if you need details on how to create or update media.

• https://docs.joinmastodon.org/methods/media/#v2
• https://docs.joinmastodon.org/methods/media/#update