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 🙏

© 2026 – Pkg Stats / Ryan Hefner

ipc-link

v0.0.1

Published

Connect multiple processes via IPC using node-ipc for backends

Readme

IPC-Link

IPC-Link is a mini-framework for node-ipc that is fully compatible with TypeScript (and in a near future, ECMAScript Modules). It is designed to have "connection channels" where two processes send data back and forth.

This framework has a queue system that holds Promises temporarily until the message has been replied back, and depending on the variable success, it may or may not reject said Promise.

Usage

You can check examples here.

Process One:

const { Server } = require('../../src/index');

console.log('Spawned test-one!');
new Server('test-one', { retry: 1500, silent: true })
	.on('message', console.log)
	.on('error', console.error)
	.once('start', (reason) => { console.log('Successfully started!', reason); })
	.start('Login!');
	.send('test-two', { content: 'Hello' })
	.then(console.log)
	.catch(console.error);

Proccess Two:

const { Server } = require('../../src/index');

console.log('Spawned test-two!');
new Server('test-two', { retry: 1500, silent: true })
	.on('message', message => { message.reply({ response: `${message.data.content} world!` }); })
	.on('error', console.error)
	.once('start', (reason) => { console.log('Successfully started!', reason); })
	.start('Login!');

Process One will send Process Two an object with content Hello, Process Two receives back and replies it with Hello (content sent by the first process) and sends another object with response: 'Hello world!' to Process One. Evaluating .send('test-two', { content: 'Hello' }) to Promise<{ id, success: true, response: 'Hello World' }>, which is logged to console.

Specification

It is important that you have a single IPCLink.Server instance because node-ipc is basically a singleton, and creating multiple instances of this may duplicate messages or corrupt the configuration. In a near future, node-ipc may get rewritten in a fork or in a backends/ folder in this repository for further support with latest versions of Node.js (new Buffer() is being used, which is deprecated starting from Node.js 10).

Proccess One

  1. Let server be the result of evaluating new Server(name, options);.
  2. Consider there is a message event being listened in server.
  3. Consider server.start(); has already been called.
  4. Let socketName be a string, e.g. 'world'.
  5. Let data be an object literal, e.g. { test: 'Hello ' }.
  6. Perform server.send(socketName, data);.
  7. Let senderSocket be the Socket instance from this process.
  8. Let hasSocket be the result of evaluating server.hasSocket(name);.
  9. If hasSocket is true, skip to the next point. Otherwise,
    1. connect to the socket via server.connectTo and await its evaluation.
  10. Let socket be the result of evaluating server.getSocket(name);.
    1. Let IPCSocketCollection be an object of NodeIPC.Servers.
    2. Let IPCSocketServer be the result of accessing to the property name of IPCSocketCollection.
    3. If IPCSocketServer is undefined, let socket be null. Otherwise
      1. Let socket be IPCSocketServer.socket, being this a Socket instance.
  11. If data has a property of id, let id be data.id. Otherwise let id be a random base36 number generated automatically.
  12. Let preparedData be an object where:
    • id refers to id.
    • sentBy refers to server.name.
    • data refers to data.
  13. Let stringifiedData be the result of evaluating JSON.stringify(preparedData);.
  14. Perform socket.write, sending stringifiedData to the Socket.
  15. Let temporalPromise be a Promise evaluated with new Promise();.
  16. Let resolve and reject be the first and second parameters from temporalPromise's callbacks.
  17. Let queuePromise be an object where:
    • resolve refers to resolve.
    • reject refers to reject.
  18. Let promiseCollection be the internal Promise collection from IPC-Link of type Map<string, { resolve: Function, reject: Function }>;.
  19. Perform promiseCollection.set(id, queuePromise);.
  20. Return queuePromise.

Proccess Two

  1. Let receiverServer be the result of evaluating new Server(name, options); in the target process.
  2. Let messagePayload be the result of evaluating JSON.parse(stringifiedData);.
  3. Let message be the result of evaluating new Message(receiverServer, senderSocket, messagePayload);.
  4. Send message to receiverServer's EventEmitter for its handling.
  5. Let responseData be an object.
  6. If responseData has a property of success, let success be responseData.success. Otherwise
    1. Let successArgument be the result of evaluating the third argument from Server#send.
    2. If successArgument is undefined, let success be true. Otherwise let success be successArgument.
  7. Let finalizedResponseData be an object where:
    • id refers to id.
    • success refers to success.
    • All properties of responseData are applied over the properties of id and success.
  8. Let stringifiedResponseData be the result of evaluating JSON.stringify(finalizedResponseData);.
  9. Perform senderSocket.write, sending stringifiedResponseData to the Socket.

Proccess One

  1. Let parsedResponseData be the result of evaluating JSON.parse(stringifiedResponseData);.
  2. Let responseID be the result of evaluating parsedResponseData.id.
  3. If responseID does not equals to id via Strict Equality Comparison,
    1. Ignore the request. Otherwise,
    2. Let promise be queuePromise.
      1. Let successResponse be the result of evaluating parsedResponseData.success.
      2. If successResponse is true, evaluate promise.resolve(parsedResponseData);, resolving temporalPromise with the value of parsedResponseData. Otherwise evaluate promise.reject(parsedResponseData);, rejecting temporalPromise with the value of parsedResponseData.