-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert codebase to ES6 #1126
Convert codebase to ES6 #1126
Conversation
4fde13f
to
f74b3e7
Compare
There's one Eslint error that I didn't yet figure out of it's legit or not:
At this line:
Rule details: https://eslint.org/docs/rules/require-atomic-updates |
I'm marking this already ready for review; a couple pesky lint issues to fix but otherwise ready. |
'object-curly-spacing': [2, 'always'], | ||
'one-var': [0, 'never'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a new rule.
@@ -22,24 +22,19 @@ const defaultRules = { | |||
'no-caller': 2, | |||
'no-console': 2, | |||
'no-else-return': 0, | |||
'no-empty-character-class': 2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All (except one-var
) removed rules are still applied because they're in eslint:recommend
config. Just removing as duplicates.
@simison wrote:
There is an open issue for this behaviour on eslint. They'll remove it from There is nothing racing in our case. We may just // eslint-disable-next-line require-atomic-updates
req.reference = whatever() |
Probably not related to this PR, but |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of linter work done! 👍
- app boots
- some eslint errors still need fixing
- added some comments; some of them unrelated
- after
npm run build:prod
mypublic/dist/main.js
contains nolet
andconst
andawait
, but contains a fewPromise
s. If the above file is part of the frontend build, then the code is not ES5 or I've overlooked something (like... isPromise
defined with a polyfill somewhere?). (Promises are present since ES6)
So when these are resolved or proven not issue, I'll support merge of this PR.
'no-redeclare': 2, | ||
}; | ||
|
||
const es2018rules = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bold move! 👍
angular: 1, | ||
}, | ||
env: { | ||
browser: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually might want to turn this browser
env off and simply allow document
and window
globals.
That will stop nasty bugs like where someone uses find()
and forgets to import it from lodash
, causing window.find
to be referenced and nothing would warn about it — it would just silently break.
There are some 700+ globals in browsers so little too permissive. 😁 Better be explicit about them.
Good for another PR.
To be replaced by 9c19102b
These are in server side overrids block and thus already linted.
8895e1a
to
835ff7f
Compare
This isn't critical — will be nice to fix some day but ok for now
Es we transform to promises code, we'll have plenty of these warnings with `req` object...
...these aren't enabled anywhere so no need to disable them explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot of good work on this one! 👍
- site starts
- tests pass
- linter is happy
Added a question about strict mode. Besides that, this seems ready for a merge. 🚀
@@ -50,197 +34,204 @@ const defaultRules = { | |||
}], | |||
'space-in-parens': [2, 'never'], | |||
'spaced-comment': [2, 'always'], | |||
strict: 0, | |||
strict: [2, 'never'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reasoning behind having this rule? Do we actually want to use sloppy mode? (I guess not?) Or do we address the issues of non-strict mode in a different way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So ES6 modules are always in strict mode automatically, so the declaration is redundant. That said, we have heaps of old Angular code that would prolly benefit from having it, but in my understanding, we'll be safe just by nature of us modifying and adding mostly new ES6 code and removing old Angular "ES5" code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Makes sense.
We could still benefit from strict mode in api code and tests, couldn't we? AFAIK it uses require
and module.exports
for exporting and importing. Have we used strict mode until now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was a bit worried how other open PRs might rebase onto this one, I tried #1134 and it rebased cleanly, as did a couple of others.
I didn't look in detail tbh, but seems good! Can always tweak in the future if it doesn't seem quite right.
Thanks, folks! Yeah, if something gets merged without being rebased and introduces ES5, it's fine, we can jump in and those will be super simple fixes. |
Proposed Changes
use strict
using https://github.com/5to6/5to6-codemod and enableno-strict
rulevar
→const
/let
(usingeslint --fix
and a few manual fixes)eslint --fix
can doeslint:recommended
as a base; remove rules in our custom set which would be duplicate with recommended.one-var
linter rule since we're already touching all these lines. This should make e.g. automatically replacing require→import easier later on.Testing Instructions
.eslintrc.js
— there are so many other changes that you might just want to skim through a bit and smoke test the site.npm start
works?npm run lint
green?const
/let
in sources and that they're ES5 code.