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

Decide on a deprecation policy for JS

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: Coding style
    • Labels:

      Description

      Summary:

      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.

      Strategies

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              mathewmay Mathew May
              Participants:
              Component watchers:
              Marina Glancy, Eloy Lafuente (stronk7)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 30 minutes
                  30m