StarryNight is a managment tool for use in building and testing Meteor.js applications. It's main intent is for creating HIPAA and FDA compliant Meteor apps (but it's useful for a lot more than that). Because Meteor is still young and focused on maximizing productivity, gaining marketshare, and rapid prototyping, most of the tool-kits you’ll find tend toward those goals.
StarryNight begs to differ on one critical point -- quality first! Meteor is an ideal platform for building healthcare apps that deal with biometrics, genomics, and other big data. So, lets make sure we have industrial grade quality assurance tools, with the goal of getting apps approved by the FDA and into production.
StarryNight provides a minimalistic command line tool for system architects. As the architect you specify the scaffolds your developer teams must use, and the code quality standards to which they must comply and set them to work. When problems arise you adjust the standards, and StarryNight rolls them into the work being done. Essentially, StarryNight's standards compliance focus helps you enforce software quality.
StarryNight is for anybody who wants to build an app that someone's health or wellbeing may depend on, and needs to manage federal, state, and/or market regulatory review and audits. This tool is for anybody who needs a quality control system for their team, and who wants to eliminate bugs from their applications.
It's a direct result of 2 years of working on the Meteor Cookbook and the Clinical Meteor Track, and makes extensive use of Nightwatch.js.
StarryNight now supports dynamic Npm prefixing, which means that, in theory, it should install correctly on Linux and Windows. We've had some success with Linux, but less success with Windows. Log a ticket if you have any problems. Better yet, give us a shout-out if you actually *do* get it installed on environments other than Mac. @awatson1978, forums.meteor.com, etc.
help
Prints out some information on commands that can be run and what arguments they take.
run-framework
Launches a specific test framework and running. Currently officially supports --nightwatch and tinytest-ci. For experimental support, please check the source code.
run-tests
Alias for run-framework. Will eventually support --verfication, --validation, --client, --server, and --all flags.
display-env
Display all the environment variables for Meteor (there's approximately 60 of them).
audit-permissions
Primarily for any EACCESS errors, or if you find yourself running commands with 'sudo'. Will modify file permissions on relevant files.
scaffold
Copies parts of the Reference Scaffold into your application. Will overwrite existing files. Should be run from the application root, where the .meteor directory is located.
clone
Clones a github url into the current directory. Not very smart. Does a raw clone, with any ancillary documentation in the github repository, such as the README.md.
create
Refactors the files from a directory into a package in the /packages directory. Must be run from the application root where the .meteor directory is located.
pattern
A 'smart-clone' which looks into a github repository for directories in the Reference Scaffold, and patches those files into your app. Overwrites existing files.
rename
Renames directories and files according to the pattern you specify. Is not case sensitive. The optional directory argument will scope the rename operation within the specified subdirectory. Run in the application parent directory to include tests in the /test directory.
find-and-replace
Basically the same as the rename command, but opens up files and replaces occurrences of the specified pattern in the code itself.
refactor
Runs both a rename and refactor command.
survey
Alias for run-tests. Deprecated. v1.x API.
extract-ids
Extracts element ids from the specified file. Best used on a Blaze/Spacebars html file.
extract-classes
Extracts element class names from the specified file. Best used on a Blaze/Spacebars html file.
extract-tests-for
Extracts ids from the specified file, and generate a Nightwatch command script.
generate-release-json
Generate a release.json file for use with `meteor publish-release` so you can publish a track. (Advanced tool.)
generate-ci
Add the configuration file of a "ci" provider to your application to get started with continuous integration. The command assumes that you're using the Reference Scaffold, and your app is located in a /webapp directory. Currently the choices are :
autoconfig
Generates the .meteor/nightwatch.json config file for Nightwatch to use. Parses the application and searches for .test directories, which allows you to keep tests with their associated components.
compact
Recursively searches for .meteor/local/build and screenshot directories which it will then delete to save space on your diskdrive. Can be run across repositories. Use the --scan flag to nondestructively scan.
fetch
Fetches packages directly from GitHub, bypassing the Atmosphere package server. Alias for the mgp utility. You will need to specify a git-packages.json file.
generate-travis (Deprecated. Use : generate-ci)
Add a .travis.yml file to your application to get started with continuous integration. Command assumes that you're using the Reference Scaffold, and your app is located in a /webapp directory.
generate-autoconfig
Generates the .meteor/nightwatch.json config file for Nightwatch to use. Parses the application and searches for .test directories, which allows you to keep tests with their associated components.
--root
StarryNight generally expects to be run from the root of an application, and most commands will default to running relative from the root of the application. The --root flag will adjust where a command runs relative to. Generally used for restricting a command to running from a subdirectory.
--framework
StarryNight supports a half-dozen testing frameworks; and defaults to an integrated version that uses parts from each. If a command supports the --framework flag, it will restrict the command to only modifying files associated with that particular framework.
--boilerplate
A boilerplate is a generic application scaffold that's specific to some functionality. A boilerplate differs from a package in that it's expected you'll use a boilerplate as a starting-off point. It's not a self-contained piece of code. It's more like a self-contained starting point for future code development.
--from
Many commands involve copying, moving, or renaming things from one location to another. This flag generally accepts either a relative url path or a string, depending on context.
--to
Many commands involve copying, moving, or renaming things from one location to another. This flag generally accepts either a relative url path or a string, depending on context.
--url
Specifies that the following URL should be used as an input to the command.
--mode
Specifies a testing mode for FDA review.
--debug
Prints out debug information.
--trace
Prints out even more detailed debugging information.