I don't see why this would be bad practice. If you complete half a feature during your work day then you may well want to commit it (and likely push it to a remote). Merging it to a branch others are working on is likely to be worse than not merging it until it is complete as it may simply be in a not working state.
There's nothing special about commits. Feel free to commit as many broken and non-working things as you feel like. It's not much different from saving in your editor.
It's in master (or your production branch etc) where you only want Commits That Work.
Btw, if you are re-factoring your types, you won't be able to hide that from your compiler via a simple feature flag.
Do it on a single commit? (or contiguous series of commits) It's not going to conflict with any other branch because there are no other branches ;)
I guess that large refactorings/reorganizations are harder if you have many branches, because they will inevitably lead to merging conflicts. On a linear setup, you don't have this problem.
But isn't this bad practice? My grug brain refuses to commit anything that does not pass tests. Check tests, then commit. Check tests, then commit.
You can hide your as yet incomplete feature inside an undocumented option, and work from there, without breaking anything.