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
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
Part of #16
Update: After discussing with the team, we've decided the best approach is to use a postinstall script to convertapi.tsfrom 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
Not necessary
CoderClientAPI calls #112, it would be nice to provide some documentation showing different examples of caching the data, and making it available within ReactKnown challenges