aem-core-forms-components icon indicating copy to clipboard operation
aem-core-forms-components copied to clipboard

Adding compilation option for all client libraries.

Open sakshi-arora1 opened this issue 3 months ago • 7 comments

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

  • [ ] Bug fix (non-breaking change which fixes an issue)
  • [ ] New feature (non-breaking change which adds functionality)
  • [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • [ ] I have signed the Adobe Open Source CLA.
  • [ ] My change requires a change to the documentation.
  • [ ] I have updated the documentation accordingly.
  • [ ] I have read the CONTRIBUTING document.
  • [ ] I have added tests to cover my changes and the overall coverage did not decrease.
  • [ ] All unit tests pass on CircleCi.
  • [ ] I ran all tests locally and they pass.

sakshi-arora1 avatar Sep 03 '25 07:09 sakshi-arora1

Accessibility Violations Found

Id Impact
aria-required-attr critical
empty-heading minor
label-title-only serious
target-size serious

adobe-bot avatar Sep 03 '25 08:09 adobe-bot

Accessibility Violations Found

Id Impact
aria-required-attr critical
empty-heading minor
label-title-only serious
page-has-heading-one moderate
target-size serious

adobe-bot avatar Sep 03 '25 08:09 adobe-bot

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests.

:loudspeaker: Thoughts on this report? Let us know!

codecov[bot] avatar Sep 03 '25 08:09 codecov[bot]

We should just add it for editor specific client libraries, since runtime client libraries are always included via runtime.all which already has this.

But, its upto customer they way they wish to include these individual client libs. Do you see any harm in putting this on each clientlib?

sakshi-arora1 avatar Sep 08 '25 09:09 sakshi-arora1

We should just add it for editor specific client libraries, since runtime client libraries are always included via runtime.all which already has this.

But, its upto customer they way they wish to include these individual client libs. Do you see any harm in putting this on each clientlib?

Let's just fix the original issue for now to keep the impact minimal

rismehta avatar Sep 08 '25 10:09 rismehta

We should just add it for editor specific client libraries, since runtime client libraries are always included via runtime.all which already has this.

But, its upto customer they way they wish to include these individual client libs. Do you see any harm in putting this on each clientlib?

Let's just fix the original issue for now to keep the impact minimal

But how will this impact anything?

sakshi-arora1 avatar Sep 08 '25 10:09 sakshi-arora1

@sakshi-arora1 - I am not sure this does what you want it to.

In the FACT tool we embed closure compiler v20210106 - https://git.corp.adobe.com/Granite/com.adobe.granite.fact/blob/ad2ab8bf993d0c92ded6b31be81aeded997b921a/tool/pom.xml#L773-L777 .

Looking at the source code I don't see ECMASCRIPT_2021 as a valid option for languageIn - https://github.com/google/closure-compiler/tree/v20211006 .

Sets the language spec to which input sources should conform. Options: ECMASCRIPT3, ECMASCRIPT5, ECMASCRIPT5_STRICT, ECMASCRIPT_2015, ECMASCRIPT_2016, ECMASCRIPT_2017, ECMASCRIPT_2018, ECMASCRIPT_2019, STABLE, ECMASCRIPT_NEXT

Hi @rombert , that is correct, I looked up and it seems ECMASCRIPT_2021 was introduced in version v20211107 [1]. We have a lot of existing clientlibraries which are actually already pointing to ECMASCRIPT_2021, and when I run them through the com.adobe.granite.clientlibs.compiler it doesn't error out for them. I will set ECMASCRIPT_NEXT and check.

[1] https://github.com/google/closure-compiler/wiki/Flags-and-Options/c1546742e8d7be056afa3621b15b10bf43206547

sakshi-arora1 avatar Sep 08 '25 11:09 sakshi-arora1