Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-97022

Rename legacy JS files to use .es5.js extension

    Details

    • Type: Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      We currently have the following pattern:

      • basename.es.js: "modern" JS, transpiled using Babel
      • basename.js: "legacy" JS, not transpiled, must use only features known to work in the oldest browser that we support (eg. IE11)

      At the moment we have 382 modern ".es.js" files in the liferay-portal repo and 395 legacy ".js" files. Counted those using:

      • find modules/apps/*/*/src -name '*.js' -not -name '*.es.js' | wc -l
      • find modules/apps/*/*/src -name '*.es.js' | wc -l

      Ideally, everything would just have the same extension and we'd treat all files exactly the same (ie. transpile everything) but there is some risk in touching the "old" files that we would rather leave alone. For example, there are many AUI-based files that we would like to replace over the course of the next year (which basically means rewriting their functionality from scratch), but other than that we'd prefer not to touch them.

      We could, for example switch some legacy modules to be transpiled (ie. by adding a package.json which does a "liferay-npm-scripts build", and making sure the compiled files are ignored via an ".npmbundlerrc" file, to prevent them from getting unwanted AMD module wrappers), and the run an ESLint autofix on them. That change in itself is pretty low risk because it is carried out by a machine, but the remaining lints would require manual treatment and that's where the cost starts to go up. We may end up having to exclude those files from automatic linting anyway because we're unlikely to want to go the whole distance and fix all the lints.

      So, the proposal here is instead to apply linting and formatting only to the "modern" JS, and let the "legacy" JS die off with as little direct interaction with it as possible. Because we want the default/common/majority use case to be as easy as possible, we will rename all the modern ".es.js" files to ".js", and rename all the legacy ".js" files to ".es5.js". That way, all new code gets written using the simplest and most natural extension, and we can just define a simple "ignore" glob that excludes old ".es5.js" files from being processed by Prettier or ESLint.

      There is risk here too (in renaming the files it is possible we may fail to update a reference), but we have to incur the risk somewhere: there is no risk-free path forward from here (even including alternatives like laboriously maintaining explicit white-lists or black-lists, or rule overrides targeting the same). If the lack of formatting and linting of the legacy code ends up being a problem, we can always reconsider this decision by keeping the rename and going ahead and adding linting and formatting anyway.

        Attachments

          Activity

            People

            • Assignee:
              greg.hurrell Greg Hurrell
              Reporter:
              greg.hurrell Greg Hurrell
              Recent user:
              Esther Sanz
              Participants of an Issue:
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Packages

                Version Package