Adding compilation option for all client libraries.
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.
Accessibility Violations Found
| Id | Impact |
|---|---|
| aria-required-attr | critical |
| empty-heading | minor |
| label-title-only | serious |
| target-size | serious |
Accessibility Violations Found
| Id | Impact |
|---|---|
| aria-required-attr | critical |
| empty-heading | minor |
| label-title-only | serious |
| page-has-heading-one | moderate |
| target-size | serious |
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:loudspeaker: Thoughts on this report? Let us know!
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?
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
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 - 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