Use milliseconds instead of seconds

[RangerMauve]

This would be breaking and require a major version bump, but having millisecond-level control is useful for timing and it is the granularity that is supported by all the timing APIs (setTimeout, setInterval, etc..).

[rwu823]

If you need milliseconds It just be passed stop(.1), that equal to 100ms, the seconds will keep the code shorter in most case.

[rwu823]

And maybe in next:

stop.sec(3)
// or
stop.ms(300)

[RangerMauve]

Fair enough

[eliperelman]

Still think the right answer is to use milliseconds instead of seconds. This keep the API consistent with standard methods. Not to mention, the bulk of timeouts in JS userland are probably under 1 second, which is the greater use case.

[rwu823]

@eliperelman

Yes, good point. it will be changed in next roadmap.

What do you think? if this way

stop.sec(3)
// or
stop.ms(300)

[lucianopf]

Sorry to interrupt, but I guess that only stop(300) using milliseconds it is enough to contemplate the API following the default standards.

Adding auxiliary methods just to increase the readability will in fact increase the complexity of the solution, raising the learning curve.

It seems overreacting but if you consider the variety of methods in lodash you will realize how big the API would get if they decided to comtemplate things like that.

[rwu823]

@lucianopf

hmm, it makes sense

[fregante]

sindresorhus/delay already supports milliseconds by default, is more flexible and it's smaller (no dependencies)

[rwu823]

API already changes to milliseconds