roboter streamlines software development by automating tasks and enforcing conventions.
roboter streamlines software development by automating tasks and enforcing conventions.
| Category | Status |
|---|---|
| Version |  |
| Dependencies |  |
| Dev dependencies |  |
| Build |  |
| License |  |
$ npm install roboter
Please note: Never install roboter globally, but always into the local context of your module or application.
To run roboter, execute the following command:
$ npx roboter
Since you will run this command quite often, you may want to setup a shorter alias. To do so, add the following line to your profile file, such as .profile (or the respective file of your platform):
alias bot='npx roboter'
Then you can simply run bot instead of npx roboter. In the following we will assume that you have not setup an alias like this.
roboter provides a variety of tasks. To run them, run roboter and provide the task's name as parameter:
| Name | Description |
|---|---|
analyse | Runs code analysis. |
build | Builds a project using TypeScript. |
deps | Checks for missing, outdated, and unused dependencies. |
help | Shows the help. |
license | Checks dependencies for incompatible licenses. |
qa | Runs code analysis, tests and checks dependencies. |
test | Runs tests. |
update | Updates the Node.js version. |
If you don't specify a task, the qa task is run as default task.
To get help, run npx roboter --help. To get help for a specific command, run npx roboter <command> --help.
If you need more detailed output, provide the --verbose flag for any command.
If your package.json file contains custom scripts, you can run them using roboter to have a streamlined user experience. Supposed, your package.json looks like this:
{
"scripts": {
"analyse-css": "..."
}
}
Then you can run the following command. If you specify any options, they will be handed over to the script:
$ npx roboter analyse-css
Environment variables you specify when running roboter are also available to the tasks. E.g., if you want to run tests with disabled TLS verification, run roboter as follows:
$ NODE_TLS_REJECT_UNAUTHORIZED=0 npx roboter test
analyse taskThis task runs code analysis on your code using ESLint. By default it uses the rules defined in the eslint-config-es module.
None
| Exit code | Description |
|---|---|
| 0 | Success |
| 1 | Code analysis failed |
Code analysis affects all .js, .jsx, .ts and .tsx files, but skips the following directories:
node_modules (nested)build (only top-level)coverage (only top-level)dist (only top-level)To exclude other files or directories, add an .eslintignore file to the root directory of your module or application.
To adjust the ESLint rules to be used, add an .eslintrc.json file to the root directory of your module or application. You may extend the built-in es/node configuration if you only need to change a few rules:
{
"extends": "es/node",
"rules": {
"eqeqeq": 0
}
};
build taskIf you want to use TypeScript, add the required tsconfig.json file to the root of your package to enable compilation on build.
Please note that you do not need to install TypeScript itself, as this is provided by roboter out of the box.
Any build options are configured using the aforementioned tsconfig.json file.
None
| Exit code | Description |
|---|---|
| 0 | Success |
| 1 | Build failed |
Please note that missing, outdated, or unused dependencies do not lead to an erroneous exit code. This is by design, since these situations are typically not critical, and you may want to ignore them intentionally.
None
deps taskThis task checks for missing, outdated, and unused dependencies.
None
| Exit code | Description |
|---|---|
| 0 | Success |
Please note that missing, outdated, or unused dependencies do not lead to an erroneous exit code. This is by design, since these situations are typically not critical, and you may want to ignore them intentionally.
Under some circumstances, dependencies are reported as unused, although they are actually being used. This can be caused by dynamic requires, or similar things.
If you experience such a situation, feel free to ignore the warnings.
license taskThis task checks your dependencies for incompatible licenses.
None
| Exit code | Description |
|---|---|
| 0 | Success |
| 1 | Incompatible licenses found |
roboter tries to get your dependencies' licenses from their respective package.json files and, if necessary, from a variety of other places, and tries to check the license compatibility based on a compatibility chart and a license list.
If you encounter a license incompatibility, and think that it should be fixed, please submit a pull request for either the compatibility chart or the license list.
Please note: Consider the license compatibility check of roboter only to be a suggestion, not as legal advice you can rely on. If you want to be on the safe side, consult a lawyer. the native web does not provide any warranty of any kind.
To disable the license check, omit the license field in your package.json file, or set it to the value UNKNOWN.
qa taskThis task runs the tasks analyse, test, and deps sequentially.
None
| Exit code | Description |
|---|---|
| 0 | Success |
| 1 | Code analysis or tests failed |
Please note that missing, outdated, or unused dependencies do not lead to an erroneous exit code. This is by design, since these situations are typically not critical, and you may want to ignore them intentionally.
None
test taskThis task runs unit, integration, and other tests using Mocha.
| Flag | Alias | Description |
|---|---|---|
| --type | -t | The test type, such as units, integration, … |
| Exit code | Description |
|---|---|
| 0 | Success |
| 1 | Tests failed |
roboter will look for test types in the test directory of your module or application. You can add a type by simply creating a directory with the desired name, e.g. unit, integration, performance, …
To create tests, add files with the naming schema *Tests.js (or *Tests.ts, if you use TypeScript) to your test type directories. Use Mocha's tdd interface when writing tests. Please also note that all your tests must be asynchronous, i.e. they must either use the done callback or use the async keyword:
// test/integration/databaseTests.js
suite('connect', () => {
test('connects to the database.', async () => {
// ...
});
});
The test types are run in a specific order. If present, roboter will first run unit, integration, e2e, and performance. After those test types, all remaining ones will be run in alphabetical order.
If you want to use functions shared across multiple tests or test types, create a directory test/shared and put your code into it. This directory is handled as a special case and will not be picked up as a test type.
If you need to register any additional pre or post actions (such as starting or stopping Docker containers, …) that shall be run before or after all tests of a given type, add a pre.js respectively a post.js file (or pre.ts and post.ts, if you use TypeScript), that act as standalone modules. If you want to use async and await, you have to wrap the file's content in an asynchronous IIFE:
'use strict';
(async () => {
// ...
})();
Please note: The post.js respectively post.ts file will be run no matter whether the tests themselves were run successfully or not.
If you need to set something up and tear something down across all of your test types, add a pre.js and post.js (or pre.ts and post.ts) in the test folder of your project. These work just like the test specific pre/post tasks above but are only run once before and after all tests.
To set environment variables that are available in the tests, you can create a .env file per test type:
SOME_ENV=foo
To adjust test execution, you can provide a .mocharc.json file per test type. However, the following options can not be overwritten, and are always set:
--async-only--bail--colors--exit--ui tddupdate taskThis task updates the Node.js version to the latest available LTS version as long as it is newer than the currently used version, commits it and optionally pushes the changes.
I.e. if you're on version 8.2.0, it will update to the latest LTS (at the time of writing 10.16.3). But if you're on 12.11.0 (the most current version at the time of writing), it won't change anything.
| Flag | Alias | Description |
|---|---|---|
| --no-push | -p | Prevents pushing the changes. |
| --node | -n | Whether Node.js should be updated. True by default, currently has no effect. |
| Exit code | Description |
|---|---|
| 0 | Success (either updates were made or were not necessary) |
| 1 | Update failed |
To run the tests run the following command:
$ npm run test
You can run all integration tests for one task by specifying the task name as an additional argument:
$ npm run test analyse
You can run a single integration test case by specifying the individual test as an additional argument:
$ npm run test analyse/fails-on-invalid-code
Unfortunately, this module can not be used to build itself. Hence you have to use npm for that.
To analyse the source code run the following command:
$ npm run analyse
FAQs
security holding package
The npm package roboter receives a total of 265 weekly downloads. As such, roboter popularity was classified as not popular.
We found that roboter demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers 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
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.
Security News
Research
Attackers are impersonating Sindre Sorhus on npm with a fake 'chalk-node' package containing a malicious backdoor to compromise developers' projects.
Security News
The npm package for the LottieFiles Player web component was hit with a supply chain attack after a software engineer's npmjs credentials were compromised.