timeout

| Pros| Cons| |--|--| | Dependency free | Could lead to some bad practices Can be slightly harder to track down where an internal exception was thrown

Installation

• npm install

Build

The build will not ensure a compilation was syntactically successfully it will only try to transpile all your code.

• npm run build

Running

This is a helper package running it doesn't do anything. The index.ts is just some exported functions. But hey who am I to stop you npm run start.

Perhaps you meant run the tests?

Testing

Run the test suite using the following commands:

• npm run test

Usage

Start with adding it as a dependency: npm -i @commission-on-post/timeout In Your code

// import the library
import timeout from "@commission-on-post/timeout"

// Your code
function myLongRunningFunc(): Promise<string>{
    // Some promise that may take a long time to execute
    return new Promise((executer) => setTimeout(() => executer("I am a function that takes 5 seconds to run"), 5000));
}

// usage
console.log(await timeout(myLongRunningFunc, 10000)) // PRINTS: "I am a function that takes 5 seconds to run"
console.log(await timeout(myLongRunningFunc, 200)) // ERRORS: Uncaught Exception - timeout exceeded

Remarks

• The timer usage in the timeout function is self resetting so wrapping the timeout call in another function and calling it repeatedly is safe.
• There are several ways to make a call that explodes inside the context of the timeout function and is not handled properly as an exception.
  • If you would like to submit a pull request that captures aforementioned errors I will gladly approve it. At this time the limitations of TS prevent us from catching all internal exceptions generated in some contexts.