Most of the file changes are here, but you can probably ignore everything past the first couple of lines. Main changes to the overall file:

1. Updated the comment to list what exactly is importing the API file
2. Updated all references for the globalaxios instance tocoderAxiosInstance
3. ExportedcoderAxiosInstance
4. Updated some of the calls toaxios.isAxiosError to justisAxiosError

I feel thatcoderAxiosInstance should never be exported or exposed. If we want to modify it, we should export custom functions for that.

@BrunoQuaresma it needs to be. The VS Code extension mutates it for request stuff.

https://github.com/coder/vscode-coder/blob/df7e48db2c1e5ca2a41313bd00d9590ad64b5881/src/storage.ts#L393-L418

This is interesting, I would not expect to see other packages/projects accessing theapi/api.ts directly.

I think that's ideal long-term. Replicate the codersdk in Go

@code-asher Any preferences as for whether we have an optionalthrowOnError property that determines how the client resolves errors? I feel like it'd be good to default tofalse

Most of the time, I would like to do things the Go way, and expose the errors as values, but React Query is built on the assumption that if something fails, you just throw the error directly, and RQ will be the one to catch/sanitize it

Ohhh yeah good point, I forgot about how React Query does it. AthrowOnError property sounds like a good idea, but will that make the types difficult? Maybe we default to throwing for now, since that is the status quo anyway.

So my thinking was that if you set up the client withthrowOnError = false, the usage looks like this:

const{ err, data}=awaitclient.getWorkspaces();

And if the client is set up to betrue, it looks like this:

// err no longer exists in the return typeconst{ data}=awaitclient.getWorkspaces();

We'd have to get a bit in the weeds of TypeScript's type system, and might have to do some type assertions for our own sanity, but I want to say it wouldn't be that bad

If the types seem chill then I am in support!