Convert to ES6, Promises, async and await. #137
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Converts the entire project to use ES6 Typescript, and converts all promise based code (that I could find) to use async/await.
This makes all of the Promise-based code we had before look a lot nicer. Compare e.g. test/mode/modeInsert.test.ts, which used to be an awful mess of
.then()
, with how nice it looks now! Since a good chunk of the VSC API is promise-based, I think this will help beautify a lot of our code in the future.There is a drawback to this approach, which is that until microsoft/vscode#2778 gets resolved, I had to disable some of the ES6 features we were using that are currently hidden behind node flags. These are:
function foo(x: number = 6)
function foo(...x: number[])
export default function foo()
I don't see these things as a huge loss compared to the gain of async/await. The frustrating thing is that if you do e.g. use default arguments, you get a fairly obscure error message during runtime that, if you've never seen it before, could be pretty confusing. If the VSC team gets back to us quickly on microsoft/vscode#2778 it won't be a big issue, but if not we could catch it by wrapping import statements in a try catch and giving a more helpful error message.
I also took the opportunity to make a few minor stylistic changes:
for ... of
in some places.for ... of
is objectively better thanfor (let i = 0; i < arr.length; i++) { let obj = arr[i]...
and subjectively better than_.forEach
because it is prettier. 😄Hopefully the above isn't contentious and I can sneak it in this PR 😉