npm installin your Strider repo. The Strider Extension Loader, which is itself a NPM module, performs the actual plugin loading when Strider starts up. Another advantage of Strider plugins being NPM modules is that it’s also easy to share and collaborate on code, given all the existing tools and community support that comes with npmjs.org.
npm testwhen a
package.jsonfile is found in the project root. Not only that, but worker plugins can communicate with each other using an EventEmitter API. This enables separation of concerns and re-use among plugins. Case in point, the strider-qunit plugin doesn't itself care whether you run qunit tests on BrowserStack or Sauce Labs, or even on your own in-house browser cluster—it just emits and listens for certain events.
Because workers can be distributed across a network for scaling and security purposes, they don't have direct access to the database, but rather send and receive data through an EventEmitter. More examples of some of our worker plugins include strider-python and strider-browserstack.
strider.jsonwith the following code:
which essentially entails specifying a string of HTML for the corresponding block id, and Strider will then substitute that block when rendering pages. We think this has a great deal of potential in allowing you to tailor Strider’s interface to your needs. For a bit more detail on editing templates, head on over to our documentation on GitHub.
Not sure what extensions you need for your testing and deployment system? We’re happy to help, just send us an email at firstname.lastname@example.org.