Uploaded image for project: 'Moodle Community Sites'
  1. Moodle Community Sites
  2. MDLSITE-6080

Decide on a deprecation policy for JS


    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Low Low
    • Coding style


      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.

      1. Status quo
        1. Any JS can be removed at the discretion of the Developer, Peer reviewer & Integrator in a joint agreement (With no stubs remaining)
      2. The mixed strategy
        1. Anything that is 'Public facing' could have a deprecation policy applied
        2. Anything internal to a module can be removed as long as the behaviour is replicated or managedĀ 
      3. The full deal
        1. 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)

      Responsibilities during upgrades:

      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

      Other thoughts:

      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.

            Unassigned Unassigned
            mathewmay Mathew May
            0 Vote for this issue
            3 Start watching this issue


                Original Estimate - Not Specified
                Not Specified
                Remaining Estimate - 0 minutes
                Time Spent - 30 minutes

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.