use eslint-plugin-es5 to enforce ES5 #107
Conversation
brodybits
force-pushed
the
add-and-use-eslint-plugin-es5
branch
from
4c30ff8
to
227290d
Compare
.eslintrc.yml
Outdated
| extends: | ||
| # FUTURE TBD: | ||
| # - 'eslint:recommended' | ||
| - 'plugin:es5/no-es2016' | ||
| parserOptions: | ||
| ecmaVersion: 6 |
There was a problem hiding this comment.
The question https://github.com/xmldom/xmldom/pull/106/files/2181dcbda3b0e27d9033a6b3dd988a912995d6cd#r471948818 got me thinking if we need these constraints in the top-level .eslintrc.yml, now that we have the constraint in lib/.eslintrc.yml.
I had actually wanted to enforce 'plugin:es5/no-es2015' at the top level, and only relax it in test, but I don't know how to do this and may raise an issue on the plugin. Any ideas would be awesome.
Thanks for the quick reviews. I will probably merge these later today.
There was a problem hiding this comment.
Well I think configuring it to a more current version on the top level and only restricting it in lib makes a lot of sense, assuming we might be looking into ways to allow more modern syntax also in lib at some point in time. In that case we would only need to remove the limitation for lib.
There was a problem hiding this comment.
I have now put ecmaVersion back to 11 and added back es2020: true in env above, like I did in PR #106, removed 'plugin:es5/no-es2016', and added explicit plugins with es5 above, hope it is OK. I put this PR in draft since I would like to merge PR #106 first.
Please let me know within the next day if you see any issues, otherwise I would like to finish with merging #106 & #107.
should guard against newer ES6 syntax that could lead to issues with some ES5 environments such as: - Jint - https://github.com/sebastienros/jint - Duktape - IE11 - Android pre-5.0 WebView (already past EOL) as discussed in PR xmldom#91 - xmldom#91
brodybits
force-pushed
the
add-and-use-eslint-plugin-es5
branch
from
286679e
to
4dbb226
Compare
brodybits
changed the title
The purpose is to avoid ES6 items that may cause issues with older engines, as discussed in PR #87.
This should guard against newer ES6 syntax that could lead to issues with some ES5 environments such as:
This PR is based on PR #106.
I would appreciate a quick review from someone, if possible.