5 ms·

The new stable timers API in Node 16, combined with top-level await, means that you can now easily sleep in an ESM Node script, like this: import { setTime

The new stable timers API in Node 16, combined with top-level await, means that you can now easily sleep in an ESM Node script, like this: import { setTimeout } from 'timers/promises'; await setTimeout(1000); console.log("awake"); (But note that you'll have to activate ESM mode to write this script, e.g. by writing it in a `.mjs` file instead of a `.js` file or by adding a setting to package.json.) https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1 https://redfin.engineering/node-modules-at-war-why-commonjs-...

capableweb 6y ago
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.
- geewee 6y ago
  I think this is the only "Javascript has too few third party libraries" take I've ever heard.
  - capableweb 6y ago
    Never said it should be a third party library, the core team can release libraries as well if they wanted to you know.
    - hn_throwaway_99 6y ago
      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/std@0.93.0 https://deno.land/std@0.93.0, 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.
    - throwanem 6y ago
      The core team does release a library. It comes with every install, and that's why we call it "standard".
      - capableweb 6y ago
        The original point was that not everyone want all these syntactic sugar "features" shipped with the core runtime...
        jakelazaroff 6y ago
        What’s the syntactic sugar feature here? Top-level await is part of the language spec.
        throwanem 6y ago
        One into which you have to opt in, yet.
        eyelidlessness 6y ago
        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.
- fny 6y ago
  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.
- w-j-w 6y ago
  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.
- cipher_system 6y ago
  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.
- RedShift1 6y ago
  That kind of reasoning got us into the whole pad-left misery.
  - capableweb 6y ago
    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.
- ReptileMan 6y ago
  Like left pad
- megous 6y ago
  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.
eloff 6y ago
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); }); }
- davidkunz 6y ago
  ... or even more easily by: const wait = require('util').promisify(setTimeout)
  - Mogzol 6y ago
    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_custom_promisified_functions https://nodejs.org/dist/latest-v16.x/docs/api/util.html#util...
- motogpjimbo 6y ago
  You don't need `async` here, since your function explicitly returns a promise.
  - whatl3y 6y ago
    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.
mjgs 6y ago
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?
- shriek 6y ago
  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 https://nodejs.org/api/esm.html#esm_enabling
  - mjgs 6y ago
    Yeah but it seems like it might be easier to just start using .mjs everywhere, no?
    - ranguna 6y ago
      I don't think so.
      - mjgs 6y ago
        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.
        ranguna 6y ago
        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.
mariushn 6y ago
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.

capableweb 6y ago

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.

geewee 6y ago
I think this is the only "Javascript has too few third party libraries" take I've ever heard.
- capableweb 6y ago
  Never said it should be a third party library, the core team can release libraries as well if they wanted to you know.
  - hn_throwaway_99 6y ago
    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/std@0.93.0 https://deno.land/std@0.93.0, 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.
  - throwanem 6y ago
    The core team does release a library. It comes with every install, and that's why we call it "standard".
    - capableweb 6y ago
      The original point was that not everyone want all these syntactic sugar "features" shipped with the core runtime...
      - jakelazaroff 6y ago
        What’s the syntactic sugar feature here? Top-level await is part of the language spec.
        throwanem 6y ago
        One into which you have to opt in, yet.
        eyelidlessness 6y ago
        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.
fny 6y ago
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.
w-j-w 6y ago
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.
cipher_system 6y ago
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.
RedShift1 6y ago
That kind of reasoning got us into the whole pad-left misery.
- capableweb 6y ago
  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.
ReptileMan 6y ago
Like left pad
megous 6y ago
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.

eloff 6y ago

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); }); }

davidkunz 6y ago
... or even more easily by: const wait = require('util').promisify(setTimeout)
- Mogzol 6y ago
  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_custom_promisified_functions https://nodejs.org/dist/latest-v16.x/docs/api/util.html#util...
motogpjimbo 6y ago
You don't need `async` here, since your function explicitly returns a promise.
- whatl3y 6y ago
  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.

mjgs 6y ago

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?

shriek 6y ago
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 https://nodejs.org/api/esm.html#esm_enabling
- mjgs 6y ago
  Yeah but it seems like it might be easier to just start using .mjs everywhere, no?
  - ranguna 6y ago
    I don't think so.
    - mjgs 6y ago
      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.
      - ranguna 6y ago
        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.

mariushn 6y ago

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.