Part of #16

Update: After discussing with the team, we've decided the best approach is to use a postinstall script to convert api.ts from TS to JS using Bun or similar. This will alleviate concerns about drift, release, and breaking changes. In addition, we will need to update our Axios instance to avoid collisions - an update which is documented in this ticket.

Another Update: going with a vendored approach as per discussion here.

What we need

Should haves

• The user should have the ability to bring the Coder SDK in directly, and make API calls for any officially-supported Coder endpoint

Not necessary

• We do not need to need to provide the user a custom caching solution. The user should be encouraged to use whatever solution makes the most sense for their needs
• However, per Coder plugin: Add documentation for helping users cache state from CoderClient API calls #112, it would be nice to provide some documentation showing different examples of caching the data, and making it available within React

Known challenges

• Right now, we technically don't have a Coder SDK – so far, we've been directly importing the main Coder codebase into other projects, and consuming its files
  • One problem with this approach is that you need access to your build process tool's configuration file (whether that's Webpack or Vite). You need to be able to tell it that it that the files in the Coder import are not pre-compiled, and need to be processed.
  • However, Backstage locks their Webpack config file down, and does not let you modify it to avoid drift in major versions. Realistically, we may need to make a dedicated SDK