fix(lib): typo in error message

[Kerumen]

The PR is now only a fix for a typo problem.

---

It's useless to add an await when we already return a promise.

See the eslint rule for example: https://eslint.org/docs/rules/no-return-await

(also fixed a small typo)

Edit: initially I removed both 2 awaits but as the first one is required to check the error, I created a variable to remove the return await.

Tell me what do you think :)

[codecov]

Codecov Report

Merging #68 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #68   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines           37        37           
  Branches        12        12           
=========================================
  Hits            37        37           

Impacted Files	Coverage Δ
lib/index.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2cacf01...78d9b1f. Read the comment docs.

[vvo]

Hey there thanks for the PR, I was curious so I did my research too on this subject. It seems that the world of JavaScript developers is not quite sure about whether or not return await is an issue in term of performance and debugging information.

See:

• Remove no-return-await rule eslint/eslint#12246
• Remove no-return-await as it sets traps during code refactoring and causes inferior stack traces standard/standard#1442
• https://stackoverflow.com/questions/44806135/why-no-return-await-vs-const-x-await/44806230#44806230
• and even a previous discussion from the last place I worked at! (I forgot about it): Proposal to disable no-return-await algolia/eslint-config-algolia#78

To be honest, unless you find a bug or performance issue caused by the lines you updated, I won't be merging this.

I still welcome your changes on the typos on the errors though :)

Also, pure stylistic but I like to know whether or not a method is an async one. If you remove await from await ironStore then you now need to know that ironStore is an async function.

Thanks anyway and I hope you'll submit more PRs here!

[vvo]

The whole "no-return-await" rule/discussion seems to boil down to:

• "This is incorrect code!" (from no-return-await peeps)
• "This is less performant" (from no-return-await peeps)
• "This is less clear" (from both side)

To confirm, unless we can prove it's significantly slower in real-world conditions (not in a loop trying to produce a significant slowdown). This is a stylistic choice and one that for now I haven't jumped on so we'll keep this part as it is, thanks!

[Kerumen]

Thanks for this overview on this topic, I was "blindly" following my eslint rule.

Sorry for the useless PR, I'll accept your changes to commit only the typo fix.

[vvo]

🎉 This PR is included in version 3.1.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀