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

@yokets/ioc

v0.0.4

Published

YokeTS: An opinionated server-side Inversion of Control (IOC) ecosystem and container for Typescript.

Downloads

6

Readme

YokeTS: Inversion of Control

Join the chat at https://gitter.im/yokets/community

Note: This is a fork of the popular InversifyJS however long term, much of code may be replaced as we get closer to a 1.0 release.

Motivation

There are few libraries that already exist for doing dependency injection inside javascript (with some being typescript focused, and others including browser support):

They all work well enough depending on your use-case, however they are too low-level once you realize that your container must be dynamic based on the environment it runs in (dev vs prod, cli vs web app, serverless vs traditional).

Then there are more batteries-included frameworks that provide IoC out-the-box but also lock you into either the specific libraries they choose (orm, http server, validation) or their own proprietary libraries.

An similarly, if you prefer a framework to make all the decisions for you then one of those MAY scale with your architecture. However, if you are in the camp who prefer libraries over frameworks, there really isn't a project out there that sits in the middle, hence: YokeTS.

Design Philosophy

Testing First

There tends to be a general design flaw with many open-source JS libraries on NPM today in that they rely on global state/singletons which inherently make them difficult to use for testing. In particular, depending on the what libraries you use, running your tests in parallel inside the same process can be near-impossible. Not only does this IoC want to encourage more performant tests at scale, but will help the community achieve this with "plugins" which wrap popular projects (such as Mongoose) with more test friendly/injectable patterns.

Server Side Only

Simply put, the needs of a the client vs server are entirely different. If your use-case requires an IoC to be re-usable across both client and server, we'd love to hear about it on Gitter.

Modular

Not only do we want to wrap popular projects with an IoC friendly interface, but also give users the ability to pick-and-choose which "frameworks" they prefer (express, koa, etc) while adhering to best practices.

Asynchronous

Most imporantly, this library is built on the assumption that every project should be building their container through some asynchronous design. Meaning, if your application does not have I/O constraints (database) or change behavior depending on where it runs (deployment), then this library will be overkill. Most IoC libraries make the assumption that you are effectively going to build your container structure manually and at boot-time. This assumption easily becomes unmaintainable and breaksdown so as you want to do something like, share common code/services across both a command-line interfaces and a web application.

Example:

You have an application that depends on 3 different I/O services (redis, elasticcache, postgres). In order for your web application to be performant, you always boot up each service at start with a "pool" to re-use connections (pretty standard pattern). However, now you want to add two new components to your code base, a CLI and some serverless functions, either of which may or may not use some of those I/O services (or perhaps they conditionally use all there depending on what is invoked).

Most IoC frameworks today effectively force you to map out (through code), every different container variation in order to avoid connecting to I/O you don't need for your execution path.

  • cli:read_from_redis
  • cli:read_from_es
  • serverless:write_to_redis
  • servleless:write_to_es

So with just four different execution paths, I need to have 4 different container configurations that only register the I/O depending on what function I call (because remember, I want to ONLY make a connection to the I/O if i need to). This pretty much defeats the purpose of IoC.

With our approach, container objects are only created when they are needed, and rely on async to be smart about resource utilization. This example is also assuming you have everything in one project, what if you want to modularize across repos with their own connectivity requirements? IoC without async simply does not scale in larger projects.

Using Today

The current state of this framework is simply a fork from a PR in the inversify project that had never been merged (as it appears the project has died). You should refer to both that PR and the general InversifyJS documentation as to how to use this library until we get around to documenting.