Skip to content
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

Merged
merged 18 commits into from
Dec 4, 2019
Merged

Convert codebase to ES6 #1126

merged 18 commits into from
Dec 4, 2019

Conversation

simison
Copy link
Contributor

@simison simison commented Nov 15, 2019

Proposed Changes

  • Convert all code (server and client) to ES6:
  • Reorganise testutils to server and client subfolders for easier linting via separate server & client side overrides
  • Update Eslint config:
    • Lint everything as es6
    • Refactor to be more specific for each override section; each section has their own globals instead of keeping them together for the whole app
    • Separate client-side and server-side, as well tests and app files.
    • Use eslint:recommended as a base; remove rules in our custom set which would be duplicate with recommended.
    • Add one-var linter rule since we're already touching all these lines. This should make e.g. automatically replacing require→import easier later on.
    • Removed all redundant Eslint disabled rules

Testing Instructions

  • Please review .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?
  • Confirm that clientside built bundles don't have const/let in sources and that they're ES5 code.

@simison
Copy link
Contributor Author

simison commented Nov 24, 2019

There's one Eslint error that I didn't yet figure out of it's legit or not:

modules/references/server/controllers/reference.server.controller.js
  415:5  error  Possible race condition: `req.reference` might be reassigned based on an outdated value of `req.reference`  require-atomic-updates

At this line:

req.reference = formatReference(reference, isUserFrom);

Rule details: https://eslint.org/docs/rules/require-atomic-updates

@simison simison requested a review from mrkvon November 24, 2019 14:37
@simison simison marked this pull request as ready for review November 24, 2019 14:38
@simison
Copy link
Contributor Author

simison commented Nov 24, 2019

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'],
Copy link
Contributor Author

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,
Copy link
Contributor Author

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 simison requested a review from nicksellen November 24, 2019 14:51
@mrkvon
Copy link
Contributor

mrkvon commented Nov 26, 2019

@simison wrote:

There's one Eslint error that I didn't yet figure out of it's legit or not

There is an open issue for this behaviour on eslint. They'll remove it from eslint:recommended in the next minor release.

There is nothing racing in our case. We may just

// eslint-disable-next-line require-atomic-updates
req.reference = whatever()

@mrkvon
Copy link
Contributor

mrkvon commented Nov 26, 2019

Probably not related to this PR, but eslint-plugin-angular in package.json may want to go to devDependencies instead of dependencies.

Copy link
Contributor

@mrkvon mrkvon left a 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 my public/dist/main.js contains no let and const and await, but contains a few Promises. If the above file is part of the frontend build, then the code is not ES5 or I've overlooked something (like... is Promise 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.

Comment on lines -58 to -61
'no-redeclare': 2,
};

const es2018rules = {
Copy link
Contributor

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,
Copy link
Contributor Author

@simison simison Nov 28, 2019

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.

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.
@simison
Copy link
Contributor Author

simison commented Dec 1, 2019

@mrkvon this no longer throws eslint warnings (I simply inline-ignored the two in bin script 421ae54 and disabled another rule in eslint since it'll likely pop up quite a bit when we transform more backend code to promises. c3f4ce9

Good for one more spin before merging!

Copy link
Contributor

@mrkvon mrkvon left a 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'],
Copy link
Contributor

@mrkvon mrkvon Dec 3, 2019

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor

@nicksellen nicksellen left a 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.

@simison
Copy link
Contributor Author

simison commented Dec 4, 2019

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.

@simison simison merged commit 84d34ce into master Dec 4, 2019
@simison simison deleted the update/eslint-es6 branch December 4, 2019 18:14
@nicksellen nicksellen mentioned this pull request Dec 13, 2019
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants