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

ayeohsee

v0.1.0

Published

zero-dependency dependency injection dependency

Readme

ayeohsee

zero-dependency dependency injection dependency

Summary

Don't over-engineer your solution. This package is usable, however it is an example of simple engineering. Dependency Injection and Front End Frameworks aren't usually needed. If injection is barely needed, use closures. Only if those do not meet your needs should you use one of the included techniques. If you are architecting a 100,000 file application, use a framework. The point of this library is to illustrate how much you can accomplish with 0 tooling and no frameworks. As for the tests, I am definitely not arguing to forego a testing framework. Adjust your tooling and dependencies to your needs, and err on the side of simplicity.

Usage

Use deep imports to only get the code you need.

// Old school
var createInjector = require('ayeohsee/setter-prototype').createInjector;

// CJS
const { createInjector } = require('ayeohsee/setter-prototype');

// ESM
import { createInjector } from 'ayeohsee/setter-prototype';

If using as a raw script, make sure to include common first. Injectors that handle instantiation rely on it for supporting browsers without spread syntax.

<script src="/assets/vendor/ayeohsee/common/script.js">
<script src="/assets/vendor/ayeohsee/beans/script.js">

Container Types

Closure

Pros:

  • No libraries needed (not even this one)

Cons:

  • Completely manual

Setter-prototype

Pros:

  • Highly flexible and don't disrupt class construction

Cons:

  • Don't handle constants or factory functions
  • Require manual creation of application context

AngularJs

Pros:

  • Handles constants, factory functions, and services

Cons:

  • Requires context to be ordered so dependencies have already been injected with their own dependencies
  • Doesn't handle prototypes or classes

Beans

Pros:

  • Handles constructor arguments of other dependencies as well as values
  • Standardizes dependencies in a single location
  • Dependencies don't have to be listed in a special order

Cons:

  • Requires all proprties of the application context to have prototypes
    • However, could be amended to support constants and factory functions
  • Does not make the bean configuration fully serializable (requires prototype passed in)
    • A Node or Browser-module specific method could handle this, but no platform agnostic method
    • ES Module dynamic imports is the most-supported method, but lacks legacy support for older versions of Node and browsers
    • I plan to add support for serializable bean configuration to the ayeohsee/beans/module.mjs entry point

Symfony

Pros:

  • Handles constructor arguments, method calls, and common parameters across containers
  • Lazily builds the containers only when retrieved

Cons:

  • Just plain complicated
  • Requires manual, programmatic IOC container registration
  • Requires containers to be registered in proper order
  • Requires all proprties of the application context to have prototypes

Desired Features

  • Each container type fully tested
  • Each container type has a full browser script for legacy browsers
  • Each container type has a full browser module (ESM)
  • Each container type has a full CJS module
  • No dependencies ever