npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@martin-hughes/time-service

v0.0.7

Published

A variety of ways to manipulate the apparent time

Downloads

6

Readme

js-time-service

AKA @martin-hughes/time-service

Classes that allow the developer to manipulate time with wrapped versions of setTimeout and (later) setInterval.

I'll be up front in saying this is an immature package, and that I'm still relatively new to both TS and publishing packages - so if you see anything that's not idiomatic or good practice, please say so.

Contents

Description

Most JS environments provide setTimeout and setInterval as global functions. They are exceptionally useful, but what if you want to change their behaviour? There are two options:

  • Do something like window.setTimeout = myNewTimeout, or
  • Use a wrapper class that provides the behaviour you want.

This package provides the latter.

Motivation

Given that you can just override the global time functions, why bother with a wrapper class? Largely for isolation:

  • You can provide different behaviours to different parts of your application - which can be useful for integration testing, for a demo mode, and more.
  • Once your time service falls out of scope, it and any strange behaviour are gone! No need to remember to reset the built in functions through all possible error and return paths

On the other hand, why might you not want to use wrappers?

  • If a library you use is tightly coupled to your app and relies heavily on setTimeout or setInterval working, then this might not work for you
  • If you really can't stand 'luxon' - it's a dependency of this package.

Why is 'luxon' a dependency?

Largely because the native Date is a hot mess. This package came out of another (private) project of mine that used luxon extensively, so it uses a luxon-first philosophy.

As for "why luxon instead of <insert favorite time package>?" - that's kind of arbitrary, but it's because it seems to be the best time/date manipulation package available for what I, personally, need to do.

Examples

This is still a young package. The API is not stable.

The most trivial example possible - wrap the normal timer functions in a class.

import {BrowserTimeService} from '@martin-hughes/time-service'

const ts = new BrowserTimeService()
ts.setTimout(() => {console.log('Timeout after 10 seconds!'), 10000})

What about speeding up time a bit? Personally I like this for a demo-mode of something that normally runs in real-time.

This isn't actually implemented yet... Coming soon!

import {SpeedyTimeService} from '@martin-hughes/time-service'
import {DateTime} from 'luxon'

const startTime = DateTime.fromObject({year: 2024, month: 2, day: 20, hour: 12, minute: 0, second: 0})
const endTime = startTime.plus({day: 1})

// Make the 24 hour period given by startTime and endTime appear as though it lasts 24 seconds
const ts = new SpeedyTimeService(startTime, endTime, 24)
ts.setInterval(() => {console.log('Appears every second!')}, 3600000)

Contributing

I genuinely welcome all constructive input, regardless of whether I agree with it or not. Please feel free to raise anything at all in the Github issues for this project - even if it's a question, since that means the documentation could be better.

If you think I'm not behaving in a way that is appropriate, please say so. I try not to be deliberately rude or offensive, so it's most likely a genuine mistake!

Security

Fingers crossed you won't find a security bug, although it's always possible. Since neither npm nor Github provide a private messaging service you will need to raise security issues in the public bug tracker. If this project becomes widely used then I will see if I can change this.

Please bear the public nature of any security issues in mind if you're intending to use this library in a particularly sensitive context. Alternatively, please contact me via the issue tracker to suggest a means of establishing private reporting of security issues.

Why not just email?

I prefer to keep my email off of the internet as far as possible. There are widespread reports of people receiving spam after publishing packages on npm due to their requirement to add an email address to the public metadata for all packages.

If you look in the package metadata for @martin-hughes/time-service you will see a valid email - but one which is pretty much a throwaway for the purposes of maintaining an npm account. Don't report issues there - I won't see the reports.

Future work

Clearly this is a very immature package right now. Some things I'd like to do...

  • Perhaps TimeService implementations should decorate each other... For example, perhaps a StaticTimeService could meaningfully wrap a SpeedyTimeService so that timeouts and intervals still work but a request for the current time is still static. I'm not sure that makes total sense, but it might be cool ¯\_(ツ)_/¯
  • Split out the underlying time manipulation - currently luxon - into a strategy, in case there's a strong feeling that luxon is not acceptable, or luxon becomes deprecated (as moment.js did...)

If these tickle your fancy then please do feel free to contribute!