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.

Sign up for GitHub

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

Jump to bottom

Consider ES6+ migration #1556

Open
Martii opened this issue Dec 20, 2018 · 1 comment
Open

Consider ES6+ migration #1556

Martii opened this issue Dec 20, 2018 · 1 comment
Labels
CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. DOC Pertains inclusively to the Documentation operations. enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. migration Use this to indicate that it may apply to an existing or announced migration. needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. team biz This is similar to a meta discussion.

Comments

@Martii
Copy link
Member

Martii commented Dec 20, 2018 •
edited
Loading

The project is currently ES5.1 and it would be helpful to migrate so we can use some more features.

  1. Some of the CONTRIBUTING.md guidelines would need to be changed... especially regarding "hoisting" since the let syntax would change if it was coded hoisted. We are using some let syntax already for speed/memory considerations in key code points.
  2. I am totally not into the arrow operator and it actually makes code more difficult to read and improves laziness. 👎
  3. With the recent issue at Site sluggishness #1548 it may be prudent to dump async at some point since async and await exist. There are a few other technologies too but Promises are also a 👎 from me.
  4. I do like callbacks but when combined with our current site issue and async it seems to be error prone. Perhaps a combination of these to be allowed in CONTRIBUTING.md

While I'm at #1548 I'll do some pro tests to see how well it handles that soon after the holidays.

Open to discussion here.
@Martii Martii added enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. team biz This is similar to a meta discussion. migration Use this to indicate that it may apply to an existing or announced migration. needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. DOC Pertains inclusively to the Documentation operations. labels Dec 20, 2018
@Martii Martii pinned this issue Dec 20, 2018
@Martii
Copy link
Member Author

Martii commented Feb 13, 2020 •
edited
Loading

Note:

  • Some dep updates #1709 deprecation of request may force some async/ await usage i.e. promises. mongoose uses system promises and we have some .then, .catch syntax already.

Ref(s):

@Martii Martii mentioned this issue Feb 24, 2020
Merged
@Tomasz69-maker Tomasz69-maker mentioned this issue May 20, 2020
Open
@Martii Martii unpinned this issue Sep 10, 2020
@Martii Martii pinned this issue Sep 10, 2020
Martii added a commit to Martii/OpenUserJS.org that referenced this issue Apr 13, 2021
@Martii
Additional dep
59c3db3 
* Partially migrate to newer dep for GH API
* Adding some error protection, **but not all**, to the GH API deprecation of QSP's. This is probably temporary until a broader fix is implemented. GH importing may have to be disabled after May 5th, 2021... webhooks might be affected if the old (or new) Promise rejection fails. i.e. no more webhooks... but we'll see after the 5th of next month if not addressed.

Applies to OpenUserJS#1705

NOTE(S):
* Due to the nature of the dependency with Promises it is currently contrary to the STYLEGUIDE.md See OpenUserJS#1556 as is OpenUserJS#1729 with ES6+ syntax.
* Doing what I can to avert this chaos but the Code is spread out all over the place.
@Martii Martii mentioned this issue Apr 13, 2021
Merged
Martii added a commit that referenced this issue Apr 13, 2021
@Martii
Additional dep (#1793)
e843506 
* Partially migrate to newer dep for GH API
* Adding some error protection, **but not all**, to the GH API deprecation of QSP's. This is probably temporary until a broader fix is implemented. GH importing may have to be disabled after May 5th, 2021... webhooks might be affected if the old (or new) Promise rejection fails. i.e. no more webhooks... but we'll see after the 5th of next month if not addressed.

Applies to #1705

NOTE(S):
* Due to the nature of the dependency with Promises it is currently contrary to the STYLEGUIDE.md See #1556 as is #1729 with ES6+ syntax.
* Doing what I can to avert this chaos but the Code is spread out all over the place.

Auto-merge
@Martii Martii mentioned this issue Aug 18, 2021
Merged
@Martii Martii mentioned this issue Dec 1, 2022
Closed
16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. DOC Pertains inclusively to the Documentation operations. enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. migration Use this to indicate that it may apply to an existing or announced migration. needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. team biz This is similar to a meta discussion.
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Martii