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.
In the async/await section, it wouldn't have been the same without
mentioning our supreme leader Tj Holowaychuk and his co js library.
Basically a syntax sugar using generators over promises. Added a short
demo of how to use it with panic.
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.
An example showing how to import code was showing the root route, which
has been deprecated in favor of /panic.js. Some examples were
duplicated, such as how to import client code. Now one simply links to
the other.
`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.
Notes don't belong in core. Not sure why I included them :(
Functions are now toString'd when toJSON is called, allowing them to be
sent over the wire.
The new data method for clients is meant to set environment variables.
Send in the name of the scope and it will be merged in. This API may
change later to allow brevity.
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 gather method is now reactive with the "stage" event, so it won't execute and prematurely begin the test. The "needs" method now uses gather internally and decides when to `run`.
The "peer-done" event didn't make much sense for a centralized configuration, so it's been changed to "client-done".
Since the reporters have been moved out into the panic-cli repo, they've been removed from panic-server.
Platform details are now sent to the server. If there are no stage listeners, it automatically sends the test to all the connected clients without being picky. This will allow extensions to filter out clients that don't match the criteria.
The results of every test are saved into a list of responses, each scoped to their test.
Instead of the stack deciding which clients get the test, that's been delegated to the test instances.
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 :(
End-to-end integration with the client, where the client connects, recieves a test, it will later respond when it's ready, then the server responds when it is ready. Then each peer will run the test and report back to the original test object.
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)
When a test finishes configuration, it's piped through the new stack interface. The stack controls what tests are being served to the client, maintaining a list of queued and completed tests. As soon as a test finishes, the next one is selected.
Now each test has it's own event emitter. This'll be useful for extensions and syntactic sugar, such as when a runner is ready to run the test, or when a test finishes on a client, or when it finishes on all clients, fail events, progress events, etc...
Instead of the Response constructor creating the test ID, that's been delegated to the test itself.
The more I considered it, the messier it made the code, and didn't provide as many advantages as I was hoping. The Context has been merged into the Test constructor, as well as associated tests.
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.)
Added module for the "this" context that test runners will need. The constructor handles timeout settings, "done" callbacks, "env" variables (and merges), as well as basic input validation. It'll be used during tests as an interface to the exterior controls, like "done" events and iterables/progress reporters.
Pass in an array of objects, with optional conditional expressions/functions, and get back a list of objects that passed the conditional and parsed properly as functions. It's in the format that the server test configuration constructor will send off to the client, so that instead of being terribly verbose, you can say `response.cbs = parse(response.cbs)` and get a validated list of test objects.
There were some race conditions involving the `bump` function, where some tests were failing because synchronous code was not acting as synchronous as it should (and I'm still not quite sure what's causing it). I've removed access to the bump function in the Test constructor (side note: none of the tests broke when I did, so apparently there was no coverage).
The client logic has been revised, as some of it was untested and wouldn't be useful for quite some time. I'm be starting with the context parser, then I'll be moving onto platform/ID filtering, then onto test runners/client context instances.
Created an event emitter instance for reporters and the test stack. Currently, the only event that fires is "begin".
All tests are now named, whether by their given name or as the name "Anonymous".
