Skip to content

chore: setup initial repo #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 17 commits into from
Feb 16, 2024
Merged

chore: setup initial repo #2

merged 17 commits into from
Feb 16, 2024

Conversation

Parkreiner
Copy link
Member

@Parkreiner Parkreiner commented Feb 15, 2024

This commit lays the groundwork for moving all our Backstage plugin logic into a separate repo that will (eventually) become public and fully open-sourced.

Notes

  • The vast majority of the code comes straight from the official scaffolder, or was copied directly from the previous repo. If I didn't leave a comment on the file, it should be safe to ignore it.
  • In theory, the Coder Backstage plugin can be launched in isolated dev mode. As in, you will get a dev page with the plugin rendered inside it. However, I couldn't figure out how to get the Proxy available in dev mode (since it technically is a backend plugin), and there aren't any docs for this specific use case. So our code is right, but every query that gets sent out will just hang until the 20-second timeout. I have a thread opened in the Backstage Discord, and am hoping to hear back soon

Changes to watch out for

  • There was a bug with the auth code that wasn't obvious until the proxy broke
    • I accidentally had the boolean for checking whether the component was mounting flipped the wrong way
    • Only reason it wasn't obvious is that we were getting back a response from the Coder API too quickly

@Parkreiner Parkreiner self-assigned this Feb 15, 2024
Comment on lines +82 to +87
/**
* 2024-02-13 - The version of TechDocsAddons that Backstage ships with makes
* the TypeScript compiler complain when you try to render it as JSX. This seems
* like it's just a type mismatch issue, and things still work at runtime
*/
const FixedTechDocsAddons = TechDocsAddons as React.FC<unknown>;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea what changed between the last time we set up a Backstage repo from early last year and now, but this was complaining at me, and likely would've caused compiler issues

Comment on lines +1 to +8
import { PluginEnvironment } from './types';

describe('test', () => {
it('unbreaks the test runner', () => {
const unbreaker = {} as PluginEnvironment;
expect(unbreaker).toBeTruthy();
});
});
Copy link
Member Author

@Parkreiner Parkreiner Feb 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the first time I've seen this code. I don't understand why this is here

@@ -0,0 +1,69 @@
/**
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New component

@@ -0,0 +1,34 @@
import React from 'react';
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a new file, but this is the first time it's really being filled out

const isInitializing =
authValidityQuery.isLoading &&
authValidityQuery.isFetching &&
!authValidityQuery.isFetchedAfterMount;
Copy link
Member Author

@Parkreiner Parkreiner Feb 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The one bug fix – authValidityQuery.isFetchedAfterMount originally wasn't negated. Originally, I thought the name meant "is this query being run immediately after the mounting render?", but it's actually "is this query being run after a re-render?"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

@@ -0,0 +1,70 @@
import {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another file that isn't new, but got filled out with more stuff, and has exports defined more properly this time

Copy link
Member

@code-asher code-asher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't figure out how to get the Proxy available in dev mode

I was looking at Roadie's pull request plugin and I wonder if we drop the proxy stuff and use this API factory thing they are doing. From what I gather it could look something like:

import * as coder from "coder/site/src/api/api" // with "coder": "https://github.com/coder/coder#main" in the package.json as a dependency
export const coderApiRef = createApiRef<typeof coder>({
  id: 'coder.api',
})
export const coderPlugin = createPlugin({
  id: 'coder',
  apis: [
    createApiFactory(coderApiRef, coder),
  ],
  routes: {
    root: rootRouteRef,
  },
})

Then in components:

import useApi ...
import coderApiRef ...
const coderApi = useApi(coderApiRef);
coderApi.getWorkspaces()

I have not tried it but it seems promising! In this example I imported from coder/coder but we could do it with the existing API stuff.

@@ -0,0 +1,320 @@
import { parse } from 'valibot';
Copy link
Member

@code-asher code-asher Feb 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note for the future, we should think about pulling from coder/coder in the way the VS Code plugin does so we can get the sdk and types from there.

If we do this, as a reference the way the VS Code plugin sets the token and URL is:

import axios from "axios"
// ...
axios.defaults.baseURL = url
axios.defaults.headers.common["Coder-Session-Token"] = token

Admittedly kind of janky. At some point maybe we export a proper client factory from coder/coder.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that seems like a much better approach, especially since we have control of the API. Especially as we move towards exposing the whole Coder API (like Ben has planned), adding the types directly is going to be much more maintainable long-term

@Parkreiner
Copy link
Member Author

Parkreiner commented Feb 16, 2024

@code-asher Yeah, I've been wondering about the API factory stuff, too. It just feels weird that the main documentation for proxying makes no mention of them, and they just say to use the native fetch

There is this example page, though, which makes use of the discoveryApi. Hopefully this would do the trick, but I've got two big questions (just thinking out loud):

  1. I'm guessing that the plugin would inherit all the config options from the root directory, but we would need to make sure that holds up, and that the proxy properties are being passed down
  2. The DiscoveryApi looks pretty straightforward (it only has one function), but I don't know if there are any limits on when it can be called. Like, does it break if it's not set up with the right providers, and would those be available in isolated mode?

Still, once I get the auth PR done, I'll fiddle around with things, and see if I can't get them working

@Parkreiner Parkreiner merged commit 23795ae into main Feb 16, 2024
@Parkreiner Parkreiner deleted the mes/repo-setup-v2 branch February 16, 2024 16:50
@code-asher
Copy link
Member

Awesome, yeah I think we can punt on the API thing since running from the root works perfectly fine, but curious to see what you turn up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants