Migrate the Frontend Coder Plugin to NFS

[camilaibs]

Description

This pull request migrates the Coder frontend plugin to support the new Backstage frontend system.

• The migrated plugin is available at a new "alpha" subpath, to ensure the legacy plugin exports remain unchanged;
• The Backstage Yarn Plugin was used to help in managing dependencies versions and ensure compatibility with the new frontend system;
• Added documentation on how to install and configure the plugin for Backstage applications that support the new frontend system;
• The app for local testing was also updated to run the new alpha version of the plugin. No visual changes are expected, here's how the plugin looks in the dev app.

Entity Card

After merging this pull request it would be nice to:

• Monitor alpha usage and gather feedback
• Plan deprecation timeline for legacy exports
• Update documentation with migration guide
• Consider promoting alpha to stable in future release

[camilaibs]

This file is used by "msw" to intercept requests that should be mocked by the Backstage dev app, such as requests to Coder Proxy API. The mock service worker needs to be in this "public" folder so that the Backstage CLI can find it and serve it at localhost:3000/mockServiceWorker.js.

[camilaibs]

This filter specifies that the card should be displayed for all entities of the component kind. Is there any specific entity spec that must also be present in the entity data for the card to be displayed?

[Parkreiner]

@camilaibs Terribly sorry for the late reply and follow-up, but I'm hoping to go through the PR this week. Just getting back up to speed on everything as Coder works to start supporting the plugin more directly

[Parkreiner]

@camilaibs I'm getting ready to start the review in earnest, but I did have two questions about the changes being made to the repo.

From my understanding, Backstage introduced this Yarn plugin to make it simpler for Backstage users to ensure that their various dependencies are in sync with the Backstage mainline versions. And also, this got added around the middle of last year (probably around the time development slowed for this plugin the first time around). A key part of that is specifying Backstage versions like this:

"@backstage/core-compat-api": "backstage:^",

1. Is there anything that needs to change from the plugin authoring standpoint to make sure that we're a little bit more insulated from Backstage version changes and breaking API changes?
   • We're looking into reports from some potential customers, and they've said the current version of the plugin (based on 1.22) is breaking for later versions of Backstage (at least 1.43). We're still gathering information from them, but they've made it sound that it was the upgrade process that broke things. I assume the NFS helps with this a lot, but is there anything else we can do to maximize compatibility? I don't want to force consumers to update their Backstage deployment to continue using the plugin, when I don't know what red tape various companies have to deal with
2. With the updates that have been made so far, it looks like they've all been centered on updating the dev page, as well as getting the plugin moved to NFS. Does the PR still need to update the packages directory to keep those in sync with the new Backstage version?