As Moodle leans more and more onto JS we need to decide how we handle the removal of old JS whether that is now unused functions / variables or entire modules.
In my experience we have just removed unused JS (functions, variables and whole modules) however, we should have some discussion around this.
I can see a couple of ways to handle this.
- Status quo
- Any JS can be removed at the discretion of the Developer, Peer reviewer & Integrator in a joint agreement (With no stubs remaining)
- The mixed strategy
- Anything that is 'Public facing' could have a deprecation policy applied
- Anything internal to a module can be removed as long as the behaviour is replicated or managed
- The full deal
- Any and all JS should face the same / similar deprecation policy we apply to PHP
Any of the above strategies would most likely require a new deprecation module to handle the warnings to a developer i.e. alerts, console logs, throwing behat errors or plain throwing errors to the page (Could break the pages' JS however)
As with the different approaches above there would essentially different responsibilities during upgrades
Approach 1: places the onus onto any 3rd party developers to ensure and core JS functions they may be using still exists during the upgrade process
Approach 2: states that any third party developer can not & should not directly call any functions situated within /local this however can not be enforced by us however, If a 3rd party were to use a 'Public' JS function then they'd be warned that it was being deprecated
Approach 3: gives the largest amount of backwards compatibility but also leads to bloat and dead ends within our JS
I am still a little unsure on which approach we should take but I feel that the third approach would lead us to a similar place that our current PHP deprecation process has taken us which can be cumbersome at the best of times and painful in the worst.