Security News
JavaScript Leaders Demand Oracle Release the JavaScript Trademark
In an open letter, JavaScript community leaders urge Oracle to give up the JavaScript trademark, arguing that it has been effectively abandoned through nonuse.
Standing on the shoulders of giants, zarro is a zero- or low-conf orchestration for (primarily) dotnet/.NET build and test (eg at CI), but it's also so much more - since it's easy to add your own tasks, you can use zarro for whatever you like, but if you're looking for CI build / test / coverage* for dotnet/.NET, this might be what you're looking for.
(* coverage works well for NUnit / .NET Framework, but I haven't found a nice process for dotnet core - yet)
msbuild
?Zarro wraps msbuild, using gulp
orchestration under the hood. It does, however,
take away the pain of:
gulp-msbuild
)dotnet test
or via the NUnit CLI runner, as appropriatePerhaps (though the msbuild discovery is a bit of a PITA, especially since Microsoft likes to keep us on our toes, mixing up exactly where that's installed to, eg in vs2019. The real win comes from:
{Assembly}.Tests
for test projects
(though it will also find Test.{Assembly}
and an ubiquitous Tests
assembluy)gulp
orchestration framework to extend or override available tasksgulp
? 3 or 4? They don't play well together!Zarro has you covered here. The heart of Zarro was originally built for gulp 3.
Version 4 came out and broke everything. I didn't feel like rewriting perfectly
acceptable tasks, but I did want to keep up with the latest version of gulp
and
the speed advantages that were promised. As such, Zarro can consume and adapt
gulp 3 tasks to run under gulp 4.
npm init -y
(if you don't already have a package.json
npm install --save-dev zarro
"scripts": {
"build": "zarro @",
"test": "zarro @",
"zarro": "zarro"
}
(the test-dotnet
task should invoke zarro's inbuilt build
task (and some earlier
ones to download tooling, as required) so that when test-time comes, assemblies
are already built (required for .NET Framework / NUnit runner, and optimised for
dotnet
by performing the build and testing without rebuild)).
Add new custom tasks by invoking zarro --create-task
to guide you through
the process. This will create a skeleton task file for you under local-tasks
with some of the boiler-plating already done.
command-line switch | action |
---|---|
--create-task | guids you through creating a new local task written in typescript |
--help | shows how to use zarro |
--init | adds a "zarro" npm script to make zarro invocations easier |
--show-env | shows the observed environment variables and what tasks they affect |
--tasks | lists the task tree (built-in and yours |
There are an array of pre-defined tasks you get out of the box with zarro. I hope to eventually
provide more documentation for them, but running zarro --tasks
should tell you something
similar to:
*.Tests
or *.Test
or plain old Tests
Zarro is designed to be zero- to low- conf. You can guide many aspects of available
tasks with environment variables. Running npm run zarro -- --show-env
will show you
all observed environment variables and where they are applicable. I suggest using
cross-env
and applying these variables in one place, to keep things simpler. For
example, NExpect does the following:
"scripts": {
"zarro": "cross-env DOTNET_CORE=1 BUILD_EXCLUDE=src/PeanutButter/**/* PACK_INCLUDE=* PACK_EXCLUDE=*Tests*,CoreConsumer,src/PeanutButter/**/* TEST_EXCLUDE=src/PeanutButter/**/* zarro",
"build": "run-s \"zarro build\"",
"test": "run-s \"zarro test-dotnet\""
}
in the above:
DOTNET_CORE=1
instructs zarro to use dotnet
instead of searching for msbuild
BUILD_EXCLUDE=...
instructs zarro to exclude everything under that folder, recursively
(NExpect imports PeanutButter as a submodule to use some shared code without relying
on another package dependency)TEST_EXCLUDE
excludes PeanutButter testsPACK_INCLUDE
and PACK_EXCLUDE
control nuget packing within NExpectZarro will automatically create a .zarro-defaults
next to your package.json
if it
is not found. In here, we can add key-value-pairs of environment variables to set
when running zarro. These values will be overridden by any existing environment variables,
so if you need to override a variable which is set on the hosting system, you should
use cross-env
as above. However, for many situations, specifying environment variables
in .zarro-defaults
makes npm script setup a lot easier. For example, if we use .zarro-defaults
,
we can modify the example above:
Update package.json with:
"scripts": {
"build": "zarro @",
"test": "zarro test-dotnet"
}
Update .zarro-defaults to contain:
DOTNET_CORE=1
BUILD_EXCLUDE=src/PeanutButter/**/*
PACK_INCLUDE=*
PACK_EXCLUDE=*Tests*,CoreConsumer,src/PeanutButter/**/*
TEST_EXCLUDE=src/PeanutButter/**/*
Note also here the shorthand of @
- if a task has the same name as the npm script
used to invoke it, this is a quick way to surface that task to npm run
-space.
Zarro will also search two folders:
These can be brand-new functionality you'd like to add to your repo's build system,
or you can override existing tasks, if they don't suit you. For example, if the pack
task doesn't do exactly what you want, copy pack.js
from node_modules/zarro/gulp-tasks
into your local-tasks
folder and modify it to suit you. If you find a generic solution
to the problem you have which others might find useful or fix a bug, I'd like to know
about it. PRs for fixes and extension tasks which others could use will be appreciated.
release
can make it much
less painful to perform a release of my nuget packages, for example.
This meta task would:
Zarro provides some convenience functionality from baked-in modules. To access a module,
the global requireModule
function will resolve the correct location for you. Modules
live under the gulp-tasks/modules
folder. Most modules will return a single function,
though there are some exceptions. Some modules may be of interest to custom tasks, eg:
gulp
requireModule("gulp")
wherever you would have normally
done require("gulp")
. This gets you the patched version of gulp 4 which
will happily consume gulp 3 tasks and which has inbuilt support for help
for your tasks on both gulp 3 and 4. Most importantly, if you do not use this
export, your tasks may not be correctly registered.env
register
can register an environment variable as known with a default
value and help. See register-environment-variables.ts
for examples.
When you use this function, you can have a central configuration for
a default value for an environment variable and your environment
variable will be displayed in the --show-env
outputresolve
resolves environment variables for you. It can be invoked with
one or more variable names, so can be used to fall back from one variable
onto another. It will also resolve back values if registered.associate
associates one or more variables with one or more tasks,
primarily to show which tasks are affected by which variables when
running with --show-env
resolveArray
can resolve an environment variable to an array for you,
with an optional delimiter
parameter, which defaults to commaresolveNumber
resolves a numeric value from the named environment
value or throws if the value can't be resolved as a number, effectively
stopping execution. If you're expecting a number (eg port or max thread
count) you can simply resolveNumber
and an invalid value would cause
execution to stop with a reasonable messageresolveFlag
resolves boolean values from environment variables
true
for: "yes", "true" or "1"false
for: "no", "false" or "0"system
resolve-masks
gulp.src
where those masks can be inclusive or exclusivefind-local-nuget
nuget.exe
, automatically
downloading it if required. Use this if you need to use nuget.exe
operations
and don't want to set up your build host with a pathed nuget.exe
git-tag
git-push
git-push-tags
pad
pad-left
pad-right
There are many more utilities in there, feel free to browse the source.
If you've made it thus far, some light history might be of interest. Zarro's core functionality comes from another repo of mine: gulp-tasks which was traditionally consumed as a git submodule. However, it seems that a lot of people don't really "get" git submodules:
git submodule update --init
after
a git clone
or a git pull
. Some modern git clients are doing this for the user,
but not all of them.pull
(ie, people forget to run git submodule update --init
), then they
re-commit back the old version of the module that they have locally. So fixes tend
to become unfixedgulp-tasks
requires dependencies to be installed in the hosting repo's
package.json, meaning that (a) the hosting repo has to "know too much" about the
requirements of gulp-tasks
and (b) upstream changes may require changes to a repo's
package.json (and an npm install
). Whilst this was (eventually) automated as part
of gulp-tasks
, it seems unnecessarily complex.gulp-tasks
available via an npm packageFAQs
Some glue to make gulp easier, perhaps even zero- or close-to-zero-conf
The npm package zarro receives a total of 187 weekly downloads. As such, zarro popularity was classified as not popular.
We found that zarro demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
In an open letter, JavaScript community leaders urge Oracle to give up the JavaScript trademark, arguing that it has been effectively abandoned through nonuse.
Security News
The initial version of the Socket Python SDK is now on PyPI, enabling developers to more easily interact with the Socket REST API in Python projects.
Security News
Floating dependency ranges in npm can introduce instability and security risks into your project by allowing unverified or incompatible versions to be installed automatically, leading to unpredictable behavior and potential conflicts.