Community
Participate
Working Groups
Currently we support no-implied-eval as part of the no-eval rule. To stay more line with upstream eslint we should break it out into its own rule: http://eslint.org/docs/rules/no-implied-eval.html
I will try to fix this.
Great! The code you will want to work on is found in: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.javascript/web/eslint/lib/load-rules-async.js and the tests, which will need updating + new ones: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.javascript/web/js-tests/javascript/eslintRuleTests.js
Thanks for the direction. I reviewed ESLint and the files your pointed me to and I am hoping you can clear up some confusion. It looks like ESLint already has the rules and the tests (though the tests are a different style). It appears that you are manually writing your own version of the rules instead of using the ones from ESLint. If that is true and can you help me understand why? The biggest difference that I found is their use of "module.export". I'm just wondering if it would be easier to bring in the ESLint rules and just keep them up to date vs manually writing them. Sorry for the nob question, I just started looking at the code base of Orion and I don't understand the history yet.
(In reply to Joshua Wilson from comment #3) > Thanks for the direction. > It appears that you are manually writing your own version of the rules > instead of using the ones from ESLint. If that is true and can you help me > understand why? The Eclipse foundation lawyers have issue with the IP provenance of the contributed rules for upstream ESLint. That is the sole reason we are coding our own (because we are not allowed to use the existing ones). I would love to be able to use the existing rules from ESLint, and this is one of the reasons we keep the same names - if some day we can use the upstream rules no changes will be required on our end.
That occurred to me earlier today as a colleague was discussing IP in Eclipse. Thanks for the clarification.
Michael, is there a past and/or ongoing IPZilla discussing the reasons for not allowing use of ESLint ?
(In reply to Max Rydahl Andersen from comment #6) > Michael, is there a past and/or ongoing IPZilla discussing the reasons for > not allowing use of ESLint ? The original CQ request (with discussion) was here: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7466#c5 Since then, ESLint added a formal Contributor License Agreement, but it doesn't apply retroactively. In the legal folks' view, the only way to rectify this is for ESLint's maintainers to go through a provenance exercise -- basically tracking down the author of every line of contributed code that predates the CLA, and ensuring they agree to the CLA terms. The maintainers have not had the time for that thus far. https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8420
New Gerrit change created: https://git.eclipse.org/r/47087
The changes look good. Just one missing piece though: we need to hook the new rule up in the validator to make sure that we can change its severity. Have a look at: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/bundles/org.eclipse.orion.client.javascript/web/javascript/validator.js We either need to provide a new pref for the new rule, or just have the one pref for no-eval also control no-implied-eval. Steps: 1. use the following snippet: /*eslint-env browser */ eval('foo.bar'); //$NON-NLS-1$ setInterval(100); setTimeout(200); 2. go to the prefs and set 'Discouraged eval use' to error 3. back in the editor 'eval' is marked, but setInterval and setTimeout are not.
I think I have figured out what needed to be change. However I now have 2 commits, they both have the same Change-ID. Do I: 1)push the second 2)rebase the commits into one commit 3)reset them and use commit --amend As I understand it 2 and 3 basically do the same thing.
(In reply to Joshua Wilson from comment #10) > I think I have figured out what needed to be change. > > However I now have 2 commits, they both have the same Change-ID. > > Do I: > 1)push the second > 2)rebase the commits into one commit > 3)reset them and use commit --amend > > As I understand it 2 and 3 basically do the same thing. If you amend the previous commit (with the same change-ID) and push it (to gerrit), the gerrit change will update (and only show as one change).
As I understand it --amend only works if you haven't committed yet. Since I committed I would need to 'git reset --soft [sha index]' and then I could --amend the changes into the previous commit. Or I could just 'git rebase -i' and merge the 2 commits. My problem is that I think these 2 actions do the same thing but I am not sure.
(In reply to Joshua Wilson from comment #12) > As I understand it --amend only works if you haven't committed yet. Since I > committed I would need to 'git reset --soft [sha index]' and then I could > --amend the changes into the previous commit. Or I could just 'git rebase > -i' and merge the 2 commits. > > My problem is that I think these 2 actions do the same thing but I am not > sure. I would reset and re-commit, just to be safe :)
I made the changes and I think I figured out how to make git do what I wanted. The gerrit has been update too https://git.eclipse.org/r/47087
Please let me know if there is something else that I need to do for this issue.
Gerrit change https://git.eclipse.org/r/47087 was merged to [master]. Commit: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=30673f41b5286dfc4d942f0e1c03875857dbbb48
(In reply to Joshua Wilson from comment #15) > Please let me know if there is something else that I need to do for this > issue. Changes merged with master, thank you Joshua!
