Migrate the Frontend Coder Plugin to NFS #149
Conversation
Signed-off-by: Camila Belo <[email protected]>
Signed-off-by: Camila Belo <[email protected]>
Signed-off-by: Camila Belo <[email protected]>
Signed-off-by: Camila Belo <[email protected]>
camilaibs
changed the title
There was a problem hiding this comment.
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.
| factory(originalFactory, context) { | ||
| const { defaultQueryFilter, readEntityData } = context.config; | ||
| return originalFactory({ | ||
| filter: { kind: 'component' }, |
There was a problem hiding this comment.
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?
Signed-off-by: Camila Belo <[email protected]>
|
@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 |
| @@ -0,0 +1,9 @@ | |||
| /* eslint-disable */ | |||
There was a problem hiding this comment.
@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:^",- 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 least1.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
- We're looking into reports from some potential customers, and they've said the current version of the plugin (based on
- 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
packagesdirectory to keep those in sync with the new Backstage version?
There was a problem hiding this comment.
Hi @Parkreiner, the backstage:^ syntax instructs Yarn to resolve the package versions based on the Backstage version specified in the backstage.json file. It is more to centralize dependency management for all @backstage/* packages, simplifying maintenance, as running yarn backstage-cli versions:bump will automatically update the version in backstage.json, and all packages using "backstage:^" will follow. The pull request is creating an alpha version of the plugin, which means that people using the old plugin should not be affected. And those who wish to try the new version will take more advantage of the new frontend system when they keep Backstage updated with the latest versions.
There was a problem hiding this comment.
I would also like to tag here @freben, a colleague of mine who is a core maintainer of Backstage, so that he help me address any point that I may have left out of my answer 🙂 .
There was a problem hiding this comment.
Right. The value gained by using the yarn plugin is that version bump PRs should look more like this afterward - i.e. the main changes being in backstage.json and yarn.lock, and pretty much nothing changing in any package.json files. This also makes it a breeze to have all packages in your monorepo end up with a consistent set of dependency versions.
To be clear though; the published packages will still have all of this resolved to be ^x.y.z versions just like before you started using the yarn plugin. It's only a development time helper.
So going back to your question about insulation from breaking Backstage changes, the yarn plugin has no effect on that. The outcome from a library consumer standpoint is no different.
Sorry you had issues with cross-version compatibility. This is not a well solved problem at this point. We as framework authors do our utmost in trying to shape stable interfaces that only change when really necessary, and to properly mark those changes as semver breaking too. It has happened that we made mistakes, but more importantly there's no solid way of having distinct multi version support. That's tough to invent without ending up in a situation where authors would have to issue multiple builds per package, all custom made for one single Backstage release. And we would prefer not to have to get to that point if we can help it, because of the added cost and complexity.
If you have feedback or ideas, we are always happy to hear them - in issues, or in the framework SIG, or similar.
| @@ -0,0 +1,9 @@ | |||
| /* eslint-disable */ | |||
There was a problem hiding this comment.
Right. The value gained by using the yarn plugin is that version bump PRs should look more like this afterward - i.e. the main changes being in backstage.json and yarn.lock, and pretty much nothing changing in any package.json files. This also makes it a breeze to have all packages in your monorepo end up with a consistent set of dependency versions.
To be clear though; the published packages will still have all of this resolved to be ^x.y.z versions just like before you started using the yarn plugin. It's only a development time helper.
So going back to your question about insulation from breaking Backstage changes, the yarn plugin has no effect on that. The outcome from a library consumer standpoint is no different.
Sorry you had issues with cross-version compatibility. This is not a well solved problem at this point. We as framework authors do our utmost in trying to shape stable interfaces that only change when really necessary, and to properly mark those changes as semver breaking too. It has happened that we made mistakes, but more importantly there's no solid way of having distinct multi version support. That's tough to invent without ending up in a situation where authors would have to issue multiple builds per package, all custom made for one single Backstage release. And we would prefer not to have to get to that point if we can help it, because of the added cost and complexity.
If you have feedback or ideas, we are always happy to hear them - in issues, or in the framework SIG, or similar.
Co-authored-by: Fredrik Adelöw <[email protected]>
3 participants
Description
This pull request migrates the Coder frontend plugin to support the new Backstage frontend system.
After merging this pull request it would be nice to: