With a noop-factory this module could fill a nice niche.

var assert = require('assert');
var fn = require('noop3').factory;

var A = fn();
var B = fn();

var obj = { A, B };

assert.equal(obj.A(), undefined);

assert.equal(obj.A, A);
assert.equal(obj.B, B);
assert.notEqual(obj.B, A);

Make it sense to support typescript and flow-type

Do we know how fast noop3 is?

How much faster is it than lodash.noop?

Or jQuery.noop?

We should also experiment with using child processes or Web Workers to offload the task of doing nothing so that we can do nothing without blocking the main thread.

It would be nice if noop3 would include a module field in the package.json, which points to an ES6 module version of the code. This allows tools like Rollup to do tree-shaking on it.

This kind of packages are awesome!

Wish you can make more pkgs like this. 😝

maybe adding compressed and gzipped sizes would be helpful

love it
achim

I'm not comfortable with using code that's not linted. Like, are you kidding me? What if someone submits a PR without a semicolon or an incompatible indentation style? And typos might go unnoticed too. Please add linting as soon as possible.

missing package fields:

• main
• jsnext:main
• dev:main
• minified:main
• module
• web

missing exports:

• noop.noop
• noop.default
• noop.__esModule
• function.name
• global.noop
• window.noop
• node-gyp bindings to auto require noop globally

hi please add support for our in-house, private package manager by hashing all file names in the root dir

• The code is pretty old
• This package used as non-development dependency impacts perfomance (ex. "is-thirteen")
• We should use modern technologies as said in #1
  Also I suggest to use a vanilla.js/semicolon.js (because vapor.js is lacking security).

Currently tests only check that function returns undefined, which doesn't guarantee that it does really NOTHING. Needs more detailed tests that check against all the possible side-effects by comparing snapshots of environment before and after execution.

Currently, you have 100% test coverage, which normally is sufficient, but when you are testing the incalculable vast of nothingness, you need test coverage that gets you closer to Infinity%.

We can start by testing that nothing doesn't do anything, and increasing the code coverage to 500%.

test('nothing should not do anything', t => {
    t.throws(() => {
        noop3().doSomething();
        noop3().doAnythingAtAll();
        noop3().seriouslyJustTrySomethingSimpleItIsAllWeAsk();
        noop3().pleaseGetOffYourLazyUnicornBumAndDoSomethingForOnce();
    });
});

ideally supporting es7 async / await

https://github.com/search?q=topic%3Asom-tam&type=Repositories

Hi, I would love to use this module for my upcoming hip startup social network, but I'm afraid it'll be too slow. I need it to support async and possibly those "promises" things? I'm not sure yet if I'll need those too. Please fix asap.

Thanks

Not sure if this is on purpose or if there is something going wrong with GitHub atm.
I checked on:

• Chrome 66, macOS High Sierra 10.13.4
• FireFox Developer Edition 61.0b2, macOS High Sierra 10.13.4
• Chrome for Android

noop3 is amazing thing, but I'm afraid it's not secure enough. Can we implement a military 8192 bit algorithm encryption?

Needs support for:

• No CommonJS
• ES6 modules
• ES7 async functions
• MongoDB 3.2 & Postgresql

Can we also get some examples with non-mythical creatures that have single protruding horns? Personally would love to see a narwhal-based example.

you have done a lot of "̋̏̏̏̋̏̏̋̋̏̏̋̋̏̋̏̋̏̏̋̏̏̋̋̏̏̏̋̋̏̋̋̏̏̋̋̋̏̏̋̋̋̋̋̏̋̏̏̏̋̏̏̏̋̋̏̏̋̋̋̏̋̏̋̋̋̋̏̏̏̋̏̏̋̋̏̋̏̋̋̋̋̏̏̏̋̋̏̋̏̏̋̋̋̋̋̋̋̋̏̋̏̏̏̏̏̏̋̏̋̏̏̏̋̋̏̏̏̏̋̏̋̋̋̋̏̏̏̋̋̋̋̋̏̏̏̏̏̋ه҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈ه҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈ه҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈ه҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈̿҈ه҈̿ useful things, but those kind of things make me belive we fucking lost the cursor of software development, i don't like this package, is there any way to dislike a github project?

Just released https://github.com/inikulin/noop-fn a couple days ago. Awesome gif in readme and named function: damn, yours is much better! 😞 Should I add obsoletion note in regard of this package?