Summary
In some circumstances, only wrappers for newly added/modified classes should be generated, and existing wrappers for unchanged classes should not be overwritten. For example, in a project with a large number of wrappers, always re-generating all wrappers can contribute to longer build times than necessary when the intention is to only generate wrappers for a few classes.
💡 A manual workaround for this could be starting with a fresh config.yaml file and adding only the classes that need wrapping. This can be a cumbersome process if it needs to be done repeatedly. It also loses the existing configuration, which may be needed in future for re-generation.
💡 A possible solution for this could be to add an --overwrite option that skips existing wrappers if it is set to false. This option would default to true to maintain backward compatibility with current behaviour. However, this only works for new classes, not existing classes that have been modified and need regenerated wrappers.
💡 Another option would be to add a --selection option to specify a subset of class names to be wrapped. This requires manual intervention.
💡 One more idea would be to add an --update option that skips existing wrappers if they remain the same after regeneration. Setting this to true by default would differ from current behaviour but should not cause problems as the wrappers themselves have not changed. Wrappers for new classes should always be generated.
Summary
In some circumstances, only wrappers for newly added/modified classes should be generated, and existing wrappers for unchanged classes should not be overwritten. For example, in a project with a large number of wrappers, always re-generating all wrappers can contribute to longer build times than necessary when the intention is to only generate wrappers for a few classes.
💡 A manual workaround for this could be starting with a fresh
config.yamlfile and adding only the classes that need wrapping. This can be a cumbersome process if it needs to be done repeatedly. It also loses the existing configuration, which may be needed in future for re-generation.💡 A possible solution for this could be to add an
--overwriteoption that skips existing wrappers if it is set tofalse. This option would default totrueto maintain backward compatibility with current behaviour. However, this only works for new classes, not existing classes that have been modified and need regenerated wrappers.💡 Another option would be to add a
--selectionoption to specify a subset of class names to be wrapped. This requires manual intervention.💡 One more idea would be to add an
--updateoption that skips existing wrappers if they remain the same after regeneration. Setting this totrueby default would differ from current behaviour but should not cause problems as the wrappers themselves have not changed. Wrappers for new classes should always be generated.