Release of v3.0.0 about ms HOT 23 OPEN

Friendly bump! Canary has been working perfectly ever since it was released... I recommend pushing to stable :)

from ms.

@leerob With all due respect, I don't think people will adopt canary more organically, because most people just automatically install types from @types/ms... As such, I think to effectively find the issues with the new release (if there are any) the package should just be released as stable.

Even issue #189 demonstrates, how easily people miss the notice in the README, and as such don't install v3.

from ms.

If there's gonna be a major version bump, can we change m to min? 👀

One genuine helpful case for this is that I sometimes can't tell if m was just ms being cut off, or if it truly means minutes. Using min can help stabilise this, and then it also opens up the possibility of using mo for months.

from ms.

from ms.

canary becomes the new stable version at this point. 😂

Just ship it! 😄

from ms.

Behavior looks like it should still be same as the current version where an error gets thrown with bad input.

That's true, the behavior is unchanged since the previous version. No error gets thrown in case the input string fails to parse, though (see my previous comment). This means your proposed solution is unfortunately unsafe. See also #123.

from ms.

What is needed to finish for a stable version? I am ready to help

from ms.

In my opinion, a stable version of v3 should include #191. It would also be nice to get a published version of this change.

from ms.

Any news on this? Please let me know if anyone needs any help moving this forward, I'm happy to help.

from ms.

We're thinking about pushing the canary to stable - have y'all been able to use the canary okay without any issues?

from ms.

Yes, the canary release works great. Only downside is that the plain string type isn't accepted, which makes ms a bit of a pain when used for parsing configuration files. Then again... passing invalid strings was already somewhat undefined behavior, and now it's made crystal clear to the user. If only there was a type predicate for narrowing string to StringValue, or a utility function that accepts string and returns a distinct (and documented) value in case parsing failed... But if that's not something you'd like to add I'd understand and I'll just continue working around it with type assertions.

from ms.

The whole usecase of ms for me is to convert configuration files, so if string is dropped, I'll have to look for another package.
The comment from @meyfa tells me that string is not accepted anymore in v3, is that true?

from ms.

String looks like it is still accepted. I'm using strings on the canary build right now.

They added StringValue to 3.0, and the documentation essentially recommends wrapping the ms() function with another function that has typed input for type safety.

https://github.com/vercel/ms/tree/3.0.0-canary.1#typescript-support

from ms.

Maybe I've overlooked something obvious, but it seems to me that string is not accepted, i.e. the following fails typechecking:

const foo: string = '10s'
ms(foo)

"TS2769: No overload matches this call."

Wrapping the function as suggested by docs would be an okay solution, if in fact ms() threw consistently for every case of invalid input. It throws for empty strings, non-finite numbers, and anything that isn't a number or string, but for generic strings it returns NaN instead of throwing:

This means the type safety via try-catch is simply an illusion. Moreover, I couldn't find this behavior documented anywhere.

We'd have to use something like:

function ms2 (value: string): number | undefined {
  try {
    const parsed = ms(value as StringValue)
    if (Number.isNaN(parsed)) {
      return undefined
    }
    return parsed
  } catch (error) {
    return undefined
  }
}

which is quite a bit of boilerplate to include in every project, just for ms.

from ms.

I confirm that string is no longer accepted, which is unfortunate.

from ms.

Ah oops, my mistake. I went back and double checked the typings and reread the documentation.

You could just wrap the ms function with another and use it if you're going to use it in a lot of places:

import ms, { StringValue } from 'ms';

export function mss(value: string) {
  const x: string = 'example';
  return ms(x as StringValue);
}

They show this in the docs too. Behavior looks like it should still be same as the current version where an error gets thrown with bad input.

from ms.

very stable here...

from ms.

Only downside is that the plain string type isn't accepted, which makes ms a bit of a pain when used for parsing configuration files. Then again... passing invalid strings was already somewhat undefined behavior, and now it's made crystal clear to the user. If only there was a type predicate for narrowing string to StringValue, or a utility function that accepts string and returns a distinct (and documented) value in case parsing failed... But if that's not something you'd like to add I'd understand and I'll just continue working around it with type assertions.

@meyfa, we're open to PRs if you have an implementation in mind! We can always ship incremental improvements as minor updates too.

Here are some alternatives:

// 1. Cast to `StringValue`.
import ms, { type StringValue } from 'ms';
ms(someVar as StringValue);

// 2. Use `StringValue` in your code.
import { type StringValue as MsStringValue } from 'ms';
interface MyArgs {
  time: MsStringValue
}

// 3. Build a small wrapper.
import ms, { type StringValue } from 'ms';
export function stringMs (str: string): number {
  return ms(str as StringValue);
}

from ms.