Hi there, and thanks for the feature request.
The nature of ES3Types is that they need to be hardcoded to avoid expensive reflection libraries. Note that even referring to them by name will eventually cause an error, because if the field has been removed then it will cause issues when trying to access it using reflection. However, this would allow for auto-updating of ES3Types which would be a possible solution to your issue.
However, a lot of what ES3Types achieve can be done without any hardcoding. As mentioned in the Supported Types guide, there's a list of fields/properties which are supported without the need of an ES3Type.
There are then attributes you can add to control what else gets serialised, or to suppress something from being serialised. For example, a private field with the [SerializeField] attribute will enabled it to be serialised, and a public field with the [NonSerialized] or [Obsolete] attribute will not be serialised.
If you're adding support for Components so that they're serialised when you save GameObjects using Auto Save or ES3.Save<GameObject>, we're making it so that you can manually select which Components get serialised and plan on having this functionality available in the upcoming update. This means you will no longer need to create an ES3Type for a custom Component for it to be serialised when saving GameObjects.
Just in case there are cases where the above does not suffice, I've created a
feature request for this here.
Hope this helps!
All the best,
Joel