Addressing another panic pain point: you have to jump through insane,
unintuitive hoops just to access a single, non-dynamic client.
Useful for picking out clients and running code on JUST one, without
needing dynamic exclusion lists and `.pluck`.
A new npm script has been added, `lint`, which is triggered on the test
command after unit tests pass.
This way, greenkeeper can update lint-related deps and know if it
breaks.
Panic-client 0.2 comes with some great new improvements, like supporting back through IE6, making async functions more brief, and preventing implicit
scope injection except under a new flag, '@scope'. This commit updates
the docs to reflect the changes from panic-client, and updates the
client version dependency.
Instead of calling a method to find the length of a list, you can use a
property (which is a getter under the hood, doing the same thing as
`.len()`). This is cleaner and more intuitive, aligning itself more with
arrays.
Subclassing is now facilitated by a new method, `.chain`. It creates a
new list instance by calling the constructor property, instead of
statically creating a new ClientList instance. This allows you to
create subclasses that inherit from ClientList, without losing that
inheritance when calling `.filter` or `.pluck` (methods which create new
list instances).
The client bundle is now exported lazily, so when you import panic,
there's a `client` getter which memoizes a fs call for the client code.
This allows compatibility on pre-3.0 versions of npm, where other packages
might not be able to recursively find `panic-client`. Also, since it's a
getter, it doesn't do the file system call until it's needed.
Instead of extending the Function's prototype with the `toJSON()`
method, since the `v0.1.0` refactor all functions have a narrow entry
point, meaning you can simply call `String(callback)`. The prototype is
no longer extended. Changelog and package.json updated.
There's a new method called `.pluck` that limits a list's length,
allowing you to arbitrarily pick out clients and select them for tasks.
The version has been bumped, changelog updated and readme modified.
Also, the `.excluding` method wasn't reactively checking to see if the
exclusion set was reduced, only added to. All tests passing.
The `panic` object has a new property, `ClientList`, that allows users
to create their own lists easily. It brings in a new feature: you can
pass subgroups into the constructor as an array and it'll source it's
clients from them, allowing groups to be created from smaller
ones. Readme, changelog, npm version, and tests updated.
`panic.serve` has been replaced with `panic.server`, which accepts
`http.Server` instances instead of options and always returns the
instance. This allows you to run one server and share it, instead of
creating one for each task. Also added a changelog to keep track of...
changes.
Breaks compatibility with `panic.serve`.
The version has hit it's first ever 0.1.0, and that comes with the
change of removing `.set()` entirely, since scope is now passed with the
function that uses it in `.run()`.
All tests passing.
Added a new keyword (cross-platform) to the package.json file.
Optionally, scope variables can be sent to the clients in the `.run`
method.
Platform queries are now loosely type checked. This allows you to match
a number against a string (or vice versa), such as a version or
architecture.
filters/exclusions, all tests passing.
Eslint came with these nasty notions about alphabetizing your variable
definitions. Strict enforcement has been enabled, and empty functions
are now allowed (noop, and it was causing noise while developing).
The tests are now using mocha instead of jasmine, as I'm trying to
become more familiar with it.
The clientList is now dynamically controlled. Only connected peers are
shown, and add/remove events are fired as things change. You can now
filter a client set against criteria (platform, generic callback) and
return a new list of live updating clients, subscribed to changes on the
parent list. There's some syntax sugar also. You can create a list that
excludes another set, such as a list of browsers might be everything
that isn't a Node.js platform. You'd write that as an exclusion.
Added some basic tests for the clientList and mock logic.
When the cli was moved into a different repo, the package.json file was
never updated, causing an install failure when looking for the panic
binary entry.
The test objects and the server now use `ClientList` to contain, track, and interact with lists of socket clients.
The test constructor now has a `toJSON` method that prevents conversion of circular structures and unecessary data transfer to the clients. It also ensures that only connected clients are stored at any time, and deleted when they disconnect, emitting the `remove` event.
Hacked-out terminal interface now allows for running test files outside the panic project folder, and testing the full integration of the suite, as well as ensuring that I'm taking this in the right direction.
Most of the tests were from an age where I didn't understand how to unit test. They assumed too much about the implementation. But now I'm reformed! They've been refactored to be less obtrusive.
Each test now tracks each peer that runs it, and can dig into the server clients to see if they're still connected. As clients report that they're done, it trickles into the test and it'll match it against the number of registered runners to see if it's all finished.
The stack now has a primitive method of pushing out the next test when it's ready, so you can write multiple tests and they'll run one after the other.
Tests now have a run and end method that allow you to easily tell the test when is appropriate to begin and when it should officially end and send control to the next test.
The tests are now notified when clients join and finish.
Sadly, the tests are still failing :(
Most event emitters are now merged with the exports object, instead of having a dedicated "events" property, preventing an uncecessarily verbose API. Sockets are now held inside an object labeled by their port number to allow for multiple sockets open at once. That's important for the reporters, who'll likely be operating on a separate reporter socket.
Basic server test on `index.js` to ensure everything is working from server to client. So far, success! However, by integrating everything, there were many things that had to change, breaking the tests.
Next steps: implement client/server asynchronous discourse model, and relay socket data through the test event emitter.
Server code now powered by socket.io, basic serving logic and events. With luck, soon I'll have the socket sending out request events that are handled by the test stack.
Some dependencies were no longer necessary, so they've been removed from `package.json`.
Some code was no longer needed, so it was removed (the server events file)
Major changes: panic client and server have been separated into two separate projects. This prevents a bunch of overhead if you're installing panic on each machine you're testing against. It also helps with separation of concerns and prevents assumptive tests.
Another major change: express was becoming complicated quick for what I needed. Instead of trying to re-implement websockets over http, I'm switching over to socket.io to allow for easier full duplex data streams.
Many of the patches weren't necessary when client code was removed (like Function.parse, Object.keys, Gun extensions, etc.)
After discussing the goals for panic more with Mark and Sean, I decided to take panic in a different direction. Previously, the interface used an options object to do test setup, and was completely declarative in nature. In order to do more complex things with the framework, it would have needed new features hacked into the existing one, without a solid, well tested foundation to build on. That was a bit frightening. As radical as it was, I decided to mostly rewrite the framework to be similar to a traditional test framework (such as jasmine or mocha), with a major twist - it will send your tests out to the connected clients to be run, and you can filter which platforms/peer IDs to run on. Since the approach is more imperative, it will be more verbose, but it also allows for faster scaling, ease of adding new features, more expressive/flexible tests, greater coverage, and approachable syntax.
With luck, panic will be around for quite some time. If that's the case, it really, really needs high test coverage, so I began with jasmine from the start. In addition, who's going to trust results from an untested test framework?
You can now boot up tests from the homepage using the UI. It's powered by jQuery.
The tests are now using the latest, greatest version of gun, v0.3.
Files now organized into folder "lib" for clarity and cleanliness.
Numerous code cleanliness improvements.
Now, if errors are passed to the acknowledgement listener, they're pushed to an array of errors on that request.
Now each time there's a response, the statistics are recalculated and are passed to an optional progress callback.
Patch.js now has stronger type checking against the data it's been given.
Added more polyfills to aid in development, like wrapping console.log in a closure to bypass the console interface error.
The timeout accuracy and code clarity has been improved.
Server is now upgraded to use gun@0.3, and the level options have been better tailored to the application.
Exposed a function named "test" that takes an options object, with things like how many gun requests to fire in total, what data to send, where to put it, what peers to connect to, etc...
Exposed a Browser constructor that opens up a new window and runs the test function with the options provided, returning an interface to the window.
Added a patch function to validate the option input and provide defaults where there aren't any values.
