Open glendaviesnz opened 2 years ago
Thanks for the proposal, @glendaviesnz. I agree this would make deprecation management more straightforward.
allow better isolation of any additional utility code used by a specific deprecation's save method.
Those can be inlined in the version desperation file itself. That being said, I don't have strong opinions about the directory structure.
What problem does this address?
Object[]
definition working out where one deprecation starts and another finishesWhat is your proposed solution?
The above issues could be mitigated by:
deprecations/
folder once more than a single deprecation is addedconst deprecations = [v3, v2, v1];
;shared.js
file to which the local imports used by the deprecation can be added to ensure they remain static.V2
, etc. added to the method name.Using this approach, standard IDE functionality can be used to easily identify which version of methods is used by which deprecation, eg.
There is an example PR here which shows how this approach would look with the Cover block.
An alternative to this approach is to follow the structure adopted by Jetpack which is to have each deprecation in its own sub folder, which might allow better isolation of any additional utility code used by a specific deprecation's save method.
It would be good to hear what others think, eg.