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

@es-shims/api

v2.5.0

Published

Loosely test a package's compliance with the es-shim API

Downloads

2,800

Readme

es-shim API Version Badge

github actions coverage License Downloads

npm badge

API Contract

For any given “es-shim API”-compliant package foo, the following invariants must hold:

  • This package will run in an environment supporting the oldest JS version in which the spec’s semantics are achievable - ES3, ES5, and/or ES6. The package should indicate its minimum level of required environment support in its README.
  • The package must attempt to support node/io.js, all versions of all ES3-compliant browsers or later, Web Workers, and node-webkit. Other environments are a plus, but not expected.
  • require('foo') is a spec-compliant JS or native function. However, if the function’s behavior depends on a receiver (a “this” value), then the first argument to this function will be used as that receiver. The package should indicate if this is the case in its README.
  • require('foo').implementation or require('foo/implementation') is a spec-compliant JS function, that will depend on a receiver (a “this” value) as the spec requires.
  • require('foo').getPolyfill or require('foo/polyfill') is a function that when invoked, will return the most compliant and performant function that it can - if a native version is available, and does not violate the spec, then the native function will be returned - otherwise, either the implementation, or a custom, wrapped version of the native function, will be returned. This is also the result that will be used as the default export.
  • require('foo').shim or require('foo/shim') is a function that when invoked, will call getPolyfill, and if the polyfill doesn’t match the built-in value, will install it into the global environment.
  • require('foo/auto') will automatically invoke the shim method.
  • The only place the package may modify the environment is within its shim method.
  • Naturally, npm test must run the package’s tests.
  • In every way possible, the package must attempt to make itself robust against the environment being modified after it is required.
  • For example, require('foo'); delete Function.prototype.call; must not alter the behavior of foo.
  • The most useful technique for this is shown in this example: var callBound = require('call-bind/callBound'); var slice = callBound('Array.prototype.slice'); slice([1], 1); — this technique works in ES3 environments, and will ensure that modifying Array.prototype or Function.prototype will not interfere with the package.

Multi-shim Packages

If your package contains multiple shims, you can pass --multi to apply these invariants:

  • The package's main export must be an array of directory names, with no additional properties.
  • The entry points and respective invariants listed above apply to the subdirectories listed in the main export
  • The root must contain shim and auto entrypoints that match the same invariants described above. The shim entry point must invoke the shim entry point in each of the subdirectories listed in the main export
  • The root must NOT contain an implementation entry point.

Recommended dependencies

  • Please use the es-abstract module to ensure spec-compliant behavior via the spec’s internal abstract operations.
  • Please use the define-properties module to trivially define non-enumerable properties, where supported.
  • Please use the call-bind module to cache references to all builtin methods, to be robust against later modification of the environment.

How to denote compliance

Prominently in the package’s README, please include the following markdown:

This package implements the [es-shim API](https://github.com/es-shims/api) interface. It works in an ES3-supported environment and complies with the [spec](https://www.ecma-international.org/ecma-262/6.0/).

Please modify “ES3” as needed to the level of support, and please update the spec link so it points directly to the most relevant section of the spec it complies with.

Binary

Very simple and shallow tests that a package follows the es-shim API.

Pass --bound to indicate that the function the package is implementing depends on having a receiver (a “this” value).

Example

es-shim-api object-assign
es-shim-api array-includes --bound

Tests

Simply clone the repo, npm install, and run npm test