Vibe smarter not harder

Unobtanium.Web.Proxy is my new pet project. It is a http(s) inspection proxy that allows developers to add a web proxy to their own project. This is used in Microsoft DevProxy. In the next release the complete API of Unobtanium.Web.Proxy will be changed. Using just “native” dotnet objects to interact with Http requests.

I’ll show you how to use Github Copilot in your next breaking change migration project.

Breaking Changes 💣

This commit will show you exactly what changed, but I’ll summarize:

The DevProxy plugin architecture is transitioning from an event-based model to a functional model for better control flow and testability.

No, there will not be a complete description of the changes in this post, sorry if I misled you.

Use GitHub Copilot to migrate to the new api 🥈

The API for xxx changed from yyy to zzz, can you migrate this plugin?

If you would do it like this and you have like 30+ plugins to migrate, it takes a long time for each and every plugin and you cannot steer or tweak it in the way you want.

Ask GitHub Copilot to write a migration plan 🥇

Instead of asking for the same migration all the time, you can ask GitHub Copilot to write a full migration plan for you.

This project uses a web proxy library, and now the api is changed. Before the change we had `BeforeRequestAsync`, `BeforeResponseAsync`  and  `AfterResponse`  which allowed changing objects This will change to `OnRequestAsync`  and `OnResponseAsync`  which might be implemented and return a response. The `BasePlugin` has the new virtual Properties and the `GraphRandomErrorPlugin` is already converted. The `GenericRandomErrorPlugin` is an example of a not converted plugin

Assignment:

-	Investigate API changes
-	Create Markdown file in plugin project named `inventory.md` with: `## {PluginName}\r\n{all implemented methods}`
-	Create markdown file in plugin project named `migration.md` with detailed description on how a single plugin should be migrated
-	DO NOT CHANGE CODE, the current project won't build because of the changed API

After taking some time to investigate the API changes, I was presented with this migration plan. And with an inventory of current plugins, because I asked for it.

Tweaking 📝

The first version of the migration plan was already really good. I thought some things could be improved, so I tweaked this human readable file just a little to make the migrations more the way I wanted. Since it is a markdown file, you can easily add your own extra instructions.

## Migration instructions

- We have compilation errors, so no need to try to build the project until all plugins are migrated.
- Instead of `string.Equals(args.Request.Method.Method, "OPTIONS", StringComparison.OrdinalIgnoreCase)`, use `args.Request.Method == HttpMethod.Options` for better performance.
- Summarize changes in max two lines

### General Migration Steps

1. Migrate plugin according to the new API method (OnRequestAsync, OnRequestLogAsync, OnResponseAsync, or OnResponseLogAsync).
2. Update inventory.md to reflect the new method, leave the old methods in place using strike through.
3. Update migration.md with the new migration status

Migrate plugins like a pro 🏆

Open the plugin you want migrated and say to GitHub Copilot:

Migrate this plugin using migration.md

It reads it’s own instructions and follows them to completion.

Conclusion

Next time I’m doing any kind of API migration, I’ll follow this process again. It was smooth sailing with GitHub Copilot doing the boring stuff. Asking it to first write the instructions and then use those instruction for the task, will ensure the process will result in the desired outcome. And the added benefit is that if others built custom plugins, they can use the provided migration guide to migrate their plugins as well.