* Moved the spinner initialization to the base class.
* Got rid of the base class, it complicated testing.
Now it lives on as a utils file. Should make it easier to test the CLI.
* Added a spec file for the ListCommand.
* Added tests for all CLI commands.
* Update some old tests.
Added missing cases and tests.
Most of these are kind useless but I hope I won't have to touch them
again.
I don't actually remember why I did it this way. I probably wanted to be
a lot more strict with the keys originally which seems silly in
retrospective.
--as-json outputs the response as json, this allows you to use tools
like jq on the output which is nice.
--quiet makes it so no output is printed. I added this in case you are
looping Beau and don't want to see the output of every single request.
Example: `seq 10 | xargs -I{} beau request hi --quiet`.
I am making a couple of small changes to how external environment
variables are used. From now own everything comming from the outside,
namely the .env file and the params flag are assigned to the '_'
variable within the internal environment. This is mostly to namespace
things and make it clear where they are coming from.
This is mostly some clean up. Now plugins are checked for existence
before being required. The regex for dynamic values was improved a
little in an attemp to make it more reliable. Plugins are only required
once now.
The CLI's CWD is set to that of the config file. This makes relative
paths mentioned in the file more reliable.
This means that beau-std will automatically be loaded if available in
the same space as Beau. beau-std is a set of commonly used plugins,
these map directly to nodejs features that are commonly needed within
Beau.
I normally prefer tabs for everything, it's nice to have the ability to
set to whatever your preferred width is. Since this project uses a lot
of yaml stuff I've had to indent those tests with spaces, for
consistency's sake I've decided to use spaces everywhere.
* Added a schema validator.
This allows you to check if the given beau config is valid. Will be used
to improve the CLI and remove schema validation-type errors from the
actual code.
* Added a validate command to the CLI.
This command is a way to test the config file. Eventually it'll probably
be removed and the schema validation will run on every other command. I
have to determine how useful this is and how performance might be
affected.
If the only thing passed as a value is a dynamic value whatever it
returns will become the new value internally. This means that they are
no longer required to be strings. This also allows plugins to use native
objects and types internally to do more advance things.
You can now let Beau know you expect cookies to be passed around by
setting COOKIEJAR to true. I'd eventually like to add support for file
storage or something similar.
This gives a lot more flexibility when it comes to what a modifier can
do. They can now use any valid request option to change how the response
behaves.
This results in two important changes:
- Made changes so that we actually use the replacement regex groups.
This was supposed to happen from the start but I guess I didn't notice.
By fixing this the code for finding dependencies and the cache#parse is
now a bit more reliable.
- This also changes how we store variables in the cache (which I've been
meaning to do for a while.) removing the dollar sign that usually
preceeded all cached requests in Beau. It's all more sensible now.
There's more refactoring left to do.
It now uses a plugin registry. Plugins are loaded when the configuration
file is first parsed. When a request is made it is passed over to the
available modifiers before and after it's execution and applies
whichever changes are made. It now passes a copy instead of a reference
to provide a nicer interface.
Dynamic values have been added as a plugin type. These plugins are
javascript functions that can be called from within the beau file and
whose results are used as a replacement.
These are added along with variables to the runtime execution flow. The
current order for their execution is:
Request composition -> Dynamic Values -> Pre-Request Modifiers ->
Post-Request Modifiers.
This introduces a top level key: `hosts`. It's an array where you can
configure multiple hosts with their own requests, they share defaults
and environment with the global scope.
This allows you to have multiple paths being the same with different
endpoints and settings.
Sergio Díaz