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

@stackline/should

v1.0.2

Published

test framework agnostic BDD-style assertions

Readme

@stackline/should

test framework agnostic BDD-style assertions.

npm version license GitHub repository Docs Reddit community

Documentation | npm | Issues | Repository

Current package version: 1.0.2


Why this package?

@stackline/should is the Stackline-maintained distribution of [email protected]. It is an independent continuation of should; original authors and licenses remain credited below.

Compatibility

| Item | Value | | :--- | :--- | | Package | @stackline/[email protected] | | API target | [email protected] | | Supported Node.js | See supported framework requirements | | License | MIT | | Main entry | ./cjs/should.js | | Module entry | ./es6/should.js | | Types | ./should.d.ts | | Runtime dependencies | should-equal, should-type, should-type-adaptors, should-util |

Installation

npm install @stackline/should

Preserve existing imports and plugin resolution with an npm alias:

npm install should@npm:@stackline/should

Usage and API reference

should.js

should is an expressive, readable, framework-agnostic assertion library. The main goals of this library are to be expressive and to be helpful. It keeps your test code clean, and your error messages helpful.

By default (when you require('@stackline/should')) should extends the Object.prototype with a single non-enumerable getter that allows you to express how that object should behave. It also returns itself when required with require.

It is also possible to use should.js without getter (it will not even try to extend Object.prototype), just require('should/as-function'). Or if you already use version that auto add getter, you can call .noConflict function.

Results of (something).should getter and should(something) in most situations are the same

Upgrading instructions

Please check wiki page for upgrading instructions.

FAQ

You can take look in FAQ.

Example

var should = require('@stackline/should');

var user = {
    name: 'tj'
  , pets: ['tobi', 'loki', 'jane', 'bandit']
};

user.should.have.property('name', 'tj');
user.should.have.property('pets').with.lengthOf(4);

// If the object was created with Object.create(null)
// then it doesn't inherit `Object.prototype`, so it will not have `.should` getter
// so you can do:
should(user).have.property('name', 'tj');

// also you can test in that way for null's
should(null).not.be.ok();

someAsyncTask(foo, function(err, result){
  should.not.exist(err);
  should.exist(result);
  result.bar.should.equal(foo);
});

To begin

  1. Install it:

    $ npm install @stackline/should --save-dev
  2. Require it and use:

    var should = require('@stackline/should');
    
    (5).should.be.exactly(5).and.be.a.Number();
    var should = require('should/as-function');
    
    should(10).be.exactly(5).and.be.a.Number();
  3. For TypeScript users:

```js
import * as should from '@stackline/should';

(0).should.be.Number();
```

In browser

Well, even when browsers by complaints of authors have 100% es5 support, it does not mean it has no bugs. Please see wiki for known bugs.

If you want to use should in browser, use the should.js file in the root of this repository, or build it yourself. To build a fresh version:

$ npm install
$ npm run browser

The script is exported to window.should:

should(10).be.exactly(10)

You can easy install it with npm or bower:

npm install @stackline/should -D
# or
bower install shouldjs/should.js

API docs

Actual api docs generated by jsdoc comments and available at http://shouldjs.github.io.

Usage examples

Please look on usage in examples

.not

.not negates the current assertion.

.any

.any allow for assertions with multiple parameters to assert any of the parameters (but not all). This is similar to the native JavaScript array.some.

Assertions

chaining assertions

Every assertion will return a should.js-wrapped Object, so assertions can be chained. To help chained assertions read more clearly, you can use the following helpers anywhere in your chain: .an, .of, .a, .and, .be, .have, .with, .is, .which. Use them for better readability; they do nothing at all. For example:

user.should.be.an.instanceOf(Object).and.have.property('name', 'tj');
user.pets.should.be.instanceof(Array).and.have.lengthOf(4);

Almost all assertions return the same object - so you can easy chain them. But some (eg: .length and .property) move the assertion object to a property value, so be careful.

Adding own assertions

Adding own assertion is pretty easy. You need to call should.Assertion.add function. It accept 2 arguments:

  1. name of assertion method (string)
  2. assertion function (function)

What assertion function should do. It should check only positive case. should will handle .not itself. this in assertion function will be instance of should.Assertion and you must define in any way this.params object in your assertion function call before assertion check happen.

params object can contain several fields:

  • operator - it is string which describe your assertion
  • actual it is actual value, you can assume it is your own this.obj if you need to define you own
  • expected it is any value that expected to be matched this.obj

You can assume its usage in generating AssertionError message like: expected obj? || this.obj not? operator expected?

In should sources appeared 2 kinds of usage of this method.

First not preferred and used only for shortcuts to other assertions, e.g how .should.be.true() defined:

Assertion.add('true', function() {
    this.is.exactly(true);
});

There you can see that assertion function do not define own this.params and instead call within the same assertion .exactly that will fill this.params. You should use this way very carefully, but you can use it.

Second way preferred and i assume you will use it instead of first.

Assertion.add('true', function() {
    this.params = { operator: 'to be true', expected: true };

    should(this.obj).be.exactly(true);
});

in this case this.params defined and then used new assertion context (because called .should). Internally this way does not create any edge cases as first.

Assertion.add('asset', function() {
    this.params = { operator: 'to be asset' };

    this.obj.should.have.property('id').which.is.a.Number();
    this.obj.should.have.property('path');
})

//then
> ({ id: '10' }).should.be.an.asset();
AssertionError: expected { id: '10' } to be asset
    expected '10' to be a number

> ({ id: 10 }).should.be.an.asset();
AssertionError: expected { id: 10 } to be asset
    expected { id: 10 } to have property path

Additional projects

  • should-sinon - adds additional assertions for sinon.js
  • should-immutable - extends different parts of should.js to make immutable.js first-class citizen in should.js
  • should-http - adds small assertions for assertion on http responses for node only
  • should-jq - assertions for jq (need maintainer)
  • karma-should - make more or less easy to work karma with should.js
  • should-spies - small and dirty simple zero dependencies spies

Contributions

Actual list of contributors if you want to show it your friends.

To run the tests for should simply run:

$ npm test

See also CONTRIBUTING.

OMG IT EXTENDS OBJECT???!?!@

Yes, yes it does, with a single getter should, and no it won't break your code, because it does this properly with a non-enumerable property.

Also it is possible use it without extension. Just use require('should/as-function') everywhere.

License

MIT. See LICENSE for details.

Security maintenance: should-format3.0.3 is vendored with its original MIT license and upstream source hash. Its function-name parser now performs a linear scan instead of overlapping regex quantifiers. All CJS, ESM, standalone and browser outputs use the same corrected source; the external should-format dependency was removed. Ordinary inputs are compared with the upstream helper and adversarial input runs in an isolated process with a timeout.

Credits and original authors

Original copyright, license notices and contributor acknowledgements remain part of this distribution. Stackline maintenance does not replace authorship of the original work.

Community and Links

Use this repository's issue tracker for reproducible bugs and feature requests. Join r/Stackline for examples, usage questions and release discussions.