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

Make fine-grained JSONPackageJSONCheck suppression possible

    Details

    • Branch Version/s:
      7.2.x
    • Backported to Branch:
      Committed

      Description

      In general we want to check a bunch of things in package.json files:

      https://github.com/liferay/liferay-portal/blob/master/modules/util/source-formatter/src/main/java/com/liferay/source/formatter/checks/JSONPackageJSONCheck.java

      For example, confirm that there are no "devDependencies", and that the "build" script is always "liferay-npm-scripts build" etc.

      But there are some cases where we want to suppress some aspect of this, but not all of it, and at the moment the only way to do this is to suppress all the checks for the entire file — for example:

      https://github.com/liferay/liferay-portal/blob/672de791082b5f8ecde564d81bd2c6cce9b8925f/source-formatter-suppressions.xml#L122

      Here is an example PR where we needed to break the rules:

      https://github.com/brianchandotcom/liferay-portal/pull/77091

      This is a module where we need to declare devDependencies and provide the to other modules. This is a legitimate use case for adding devDependencies (infrastructure modules that make their contents available to other consumers); it's unlike the typical case where we want to stop devDependencies being added willy-nilly.

      So the purpose of this ticket is to see whether we can find a way to make the suppressions finer-grained. Somewhere on the scale from "check everything in the package.json" to "check nothing in the package.json", there are intermediate steps, such as "check scripts properties but not devDependencies", or "do check devDependencies, but allow whitelisted ones" etc. I don't know what balance of fine-grainedness and simplicity is optimal.

      Failing that, a last resort would be for us to "hide" the dependencies inside liferay-npm-scripts, but that's not something we're sure we'd want to do, because it obfuscates where the dependency is really coming from.

        Attachments

          Activity

            People

            • Assignee:
              support-lep@liferay.com SE Support
              Reporter:
              greg.hurrell Greg Hurrell
              Recent user:
              Clarissa Velazquez
              Participants of an Issue:
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Packages

                Version Package
                7.2.10 DXP FP2
                7.2.10.1 DXP SP1
                7.2.X
                Master