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

soren

v0.0.8

Published

stdin test runner

Downloads

2

Readme

Soren

Soren is an minimal test runner designed to help E2E tests with interactive CLI tools such as an application using Inquirer. It's flaky and experimental, please submit any issues that you might encounter.

alt-tag

Usage

$ npm install -g soren

soren binPath="./my/repo/dot.js" -- optionalArgs

Example

Example from a E2E test with the webpack-cli

'use strict';
const assert = require('assert');
/* global describe question */

// Webpack-cli -> soren binPath="YourPathToWebpackCLI" -- init
// Alternatively, clone webpack-cli and run 'Soren' inside the repo

describe('init', () => {
  question('Will your application have multiple bundles? (Y/n)', 'n', (answer) => {
    assert.equal(answer, 'n');
  });

  question('Which module will be the first to enter the application?', 'app.js', (answer) => {
    assert.equal(answer, 'app.js');
  });

  question('Which folder will your generated bundles be in? [default: dist]:',
    './dist', (answer) => {
      assert.equal(answer, './dist');
    });

  question('Are you going to use this in production? (Y/n)', 'Y', (answer) => {
    assert.equal(answer, 'Y');
  });

  question('Will you be using ES2015? (Y/n)', 'Y', (answer) => {
    assert.equal(answer, 'Y');
  });

  question(` Will you use one of the below CSS solutions?
  1) SASS
  2) LESS
  3) CSS
  4) PostCSS
  5) No
  Answer:`, 2, (answer) => {
      assert.equal(answer, 2);
    });
  question(`If you want to bundle your CSS files, what will you name the bundle? (press en
ter to skip)`, 'enter', (answer) => {
      assert.equal(answer, 'enter');
    });

  question('Name your \'webpack.[name].js?\' [default: \'prod\']:', 'dev', (answer) => {
    assert.equal(answer, 'dev');
  });
});

There's several things you may have noticed here. First of all, your interactive questions need to match exactly, as well as they have to be in order. Secondly, we're using the native assert module for node, while we figure out how to implement this nicely with other test runners.

Important

  1. Filename for each of the tests needs to be named example.stdin.js
  2. When you're running soren, describe should have the argument you pass it, as well as the filename: soren binPath=../some/path -- example
  3. Describe needs then to look like: describe('example', () => {...})

Tricks of the Trade

  1. Run Soren in a Docker container
  2. If you are producing code, leave that checks for tools like Jest and run that command after Soren has run its command. (Example: npm run E2E:soren && npm run E2E:jest)

Motivation

In the future, Soren should be consumed with a Docker container. This way, an E2E test that produces some output can be tested without consuming "Junk" code in your workspace.

What's left

  • Less flaky assertions
  • Opt in docker and usage after a CLI command has been finished