You can also do this with a wrapper around setTimeout, if you're in an older environment:

  /\*
   \* A sleep function that returns a promise.
   \*
   \* @example
   \* Sleep for 100ms
   \* ```
   \* await wait(100);
   \* ```
   \*/
  export async function wait(ms: number) {
      return new Promise(resolve => {
          setTimeout(resolve, ms);
      });
  }

... or even more easily by:

const wait = require('util').promisify(setTimeout)

That's interesting. util.promisify normally only works with functions where the callback is the final argument, which isn't the case with setTimeout. I didn't know you could customize promisify behaviour, but looking at the docs apparently you can just by setting a property on the object using the util.promisify.custom symbol [1]. That is what setTimeout is doing, which is why that code works.

[1] https://nodejs.org/dist/latest-v16.x/docs/api/util.html#util...

You don't need `async` here, since your function explicitly returns a promise.

I do that too. In ts, it helps a tiny bit - it enforces that the function will return a promise. So if that ever changes, the function TS compiler will be your backup anchor.

While this is true, I've found over time it's easier for me to quickly see in my code if I need to `await` on something if the function is an `async` function and not just that it returns a Promise.

I prefer

async function foo() { return await new Promise(...) }

as opposed to

function foo() { return new Promise(...) }

They're the same thing for the most part but the latter I have to potentially dig deeper into the function to confirm it returns a promise compared to the former.

The problem is that this is more than just a syntactic difference. There's a chance it will take two ticks to resolve instead of one.

For documentation purposes, I recommend block-commenting the `async`:

const foo = /async/ () => new Promise(...);

I did not know this and appreciate the insight! Will definitely store this back of mind and try and remember to use block comments when needing to explicitly return a promise.

That's not true if you just return the promise instead of using return await, right?

No. `async` on a function automatically defers it even if the return value is immediate.

> async function foo() { return "hello"; } foo().then(console.log); console.log("after")

after hello

const sleep = ms => new Promise(r => setTimeout(r, ms));

It doesn't need to be that tricky.

I get that the arrow function notation is less verbose, but I disagree with calling function syntax "tricky". It really doesn't matter much. You need the type on ms though (if using typescript), and export.

What’s the overall feeling on using .mjs files?

My initial thoughts were “urgh I just want to have .js files in my projects” but I’m wondering if I’ll warm to them given that they make things a lot easier.

Are people eventually just all going to use .mjs files for everything?

If you have package.json file you can still use .js file with 'type: module' in package.json.

https://nodejs.org/api/esm.html#esm_enabling

Yeah but it seems like it might be easier to just start using .mjs everywhere, no?

I don't think so.

I know it’s a bit of an apples and pears comparison, but which part of changing the file extension feels more difficult than editing package.json?

I’m thinking about new projects rather than converting existing projects.

One benefit I can see to .mjs is that if all extensions are .mjs it’s clear what type of project it is without the need to open up package.json.

With the context you've added now, I might agree. Existing projects would be a pain to rename all files compared to adding a single line to the package.json .

About new projects, I'd have to read more about this new extension, for some reason it feels like a temporary solution that'll just get merged to the normal js extension in a future release.

Yeah it totally has the feel of a temporary solution.

From what I’ve read though, there doesn’t appear to be much of a plan apart from the current solution.

My initial reaction is that I want to keep all my files with .js extension.

One thing that could potentially be problematic is for files that need to run in the browser and on the server.

Really curious to see where the community’s tea leaves settle. My guess is that people will eventually just start using the new extension.

Can I have an entire stand-alone app (not a module to be published on npm) as a module in package.json? I understand it can no longer use require() anywhere, that's ok.

The question is, why bloat the standard library with something that would take a couple of lines to implement yourself or as a library? More languages should release new features as libraries instead of forcing it into the "global" space of the standard library.

I think this is the only "Javascript has too few third party libraries" take I've ever heard.

Never said it should be a third party library, the core team can release libraries as well if they wanted to you know.

I think what you are arguing (which I agree with) is that the Node ecosystem would benefit from a set of "core" libraries that could just be installed as a separate NPM module, that are blessed by the Node core maintainers, but aren't part of a specific Node version.

Deno basically does this with the Deno standard library, e.g. https://deno.land/[email protected], and I agree that I think it's the right approach.

There is nothing "special" about wrapping setTimeout as a Promise, indeed pretty much everyone has done it at some point, so would be nice if there was a single, blessed standard version that I could just add as @node/standard in my package.json as long as I was on any supported Node version.

The core team does release a library. It comes with every install, and that's why we call it "standard".

The original point was that not everyone want all these syntactic sugar "features" shipped with the core runtime...

What’s the syntactic sugar feature here? Top-level await is part of the language spec.

One into which you have to opt in, yet.

I don’t think that’s true. It’s supported in any ESM module, per the ESM standard, without any config or runtime flags. If you mean using ESM to be the opt-in mechanism, that’s not a meaningful distinction. CJS modules and require have always been synchronous and likely always will be. Changing that would break too many things.

Because I don't want to have to download some yahoos library just to have a timeout that behaves like a promise.

I prefer my batteries included. Also importing from "timers/promises" isn't a global namespace.

I can never remember if i'm using promise-sleep, sleep-promise or any of the other available packages. Or if they stop working on a node upgrade. Also nice if people use and do the same simple things across projects.

The most common stuff I like to be part of the standard lib, either node or javascript, but it works fairly well now I guess so no biggie.

This one is not that bad. At least it takes AbortSignal, so it can be cancelled. Bonus points for that.

That said, I'll probably spend more time searching the node docs for how to import/use it than just implementing it myself.

OTOH I use promisified timer in almost all of my web scraping scripts, to reduce the load on the server, so I'm glad I'll be able to drop this thing from my utility library.

That kind of reasoning got us into the whole pad-left misery.

No, mutable package management is the main reason, together with "humanness" as the author pulled the package from the registry. The core team would hardly pull a package like that.

Like left pad

Large standard libraries are good. The more things are in the standard library for a language, the more likely it is that other 3rd party libraries play nice together.