RevDeBug
RevDeBug main website
Search…
Introduction
Installing RevDeBug server
Updating RevDeBug server
Supported langauges
C#
Java
JavaScript
API
Cleaning RevDeBug instrumentation
Data masking
Cypress automated tests integration
Python
How to guides
Recording the properties of complex user-defined objects
How to setup Notifications from RevDeBug in Microsoft Teams
Connecting GIT repository using SSH keys
RevDeBug server featuers
Dashboards
Topology
Trace
Profile
Alarms
Error monitoring
Settings & Administration
FAQ
Powered By GitBook
JavaScript
How to setup recording & monitoring for JavaScript applications

Requirements

To setup RevDeBug you will need to:

Configure RevDeBug.json with your project

Create a file revdebug.json in main app folder of your project where you have package.json to setup connection with RevDeBug Monitor.
revdebug.json
1
{
2
"host": "revdebug.server.address",
3
"port": "42734",
4
"apm": true,
5
"version": "1.0.0",
6
"solution": "Example Project",
7
"application": "Example Application",
8
"type": "module",
9
"runtime": "inject",
10
"mode": "onevent",
11
"sourceMap": true,
12
"path": "src",
13
"files": "**/*.{js,ts}",
14
"index": "src/index.html",
15
"postPath": "dist",
16
"postFiles": "*.js"
17
}
18
​
Copied!

Basic setup

Parameter
Effect
host
The hostname or IP address as a string of the RevDeBug Server.
port
The port of the RevDeBug Server, this must be a number.
webPort
The port of the record server for web projects, this must be a number. A value of 0 indicates that the appropriate port 80 or 443 be used according to the secure status.
release
The release string, normally git commit hash (retrieved automatically if not provided).
version
Human readable version string. If package.json is present this comes from the version field.
solution
Solution name. If package.json is present this comes from the name field.
application
Application name. If package.json is present this comes from the main field.
type
How to parse .js and .jsx files, can be commonjs or module. If package.json is present this comes from the type field. All .mjs, .ts and .tsx" files are always parsed as module and all .cjs files are parsed as commonjs regardless of this setting.
runtime
How the RevDeBug runtime is incorporated into the project, can be inject, local or global. The default is global, see below for details.
mode
The record mode you want this project to start in, options are continuous, onevent or standby. When in standby nothing will be recorded even if an unhandled exception occurs. A project that is set to standby or onevent can not be set to continuous through the use of the RevDeBug API and a project in standby can not be changed either. Though this setting can be overridden through the use of environment variables, see below for details.
sourceMap
Specifies whether file.map source maps are to be written alongside instrumented sources, true or false, default is false.
path
This allows you to specify a common path prefix for any files or excludes you specify for the current project or subproject. This value will also be excluded from any web project exception localization filename matching. Paths are inherited from parent projects and this path is joined with and treated as a subpath of the parent.
files
This is where you specify the files to be instrumented for this project. If a project has files then it is a full project and not just a bunch of options for command line compiling or subprojects. This can be specified as either a string or an array of strings, and each one is treated as a wildcard match specifier and all files in the current path which match are included in the project. All files of all subprojects of this project are also automatically excluded from this project.
index
For a web runtime type inject or global this specifies the name of the index HTML-ish file to be modified for the inclusion of the RevDeBug script. For a global project a <script src="__revdebug.js"> tag is inserted into the file whereas for an inject project the full RevDeBug runtime is inlined. For a global project this this is optional, if not specified then you are responsible for loading the RevDeBug runtime script somewhere yourself. This file is always relative to the root path of the project irrespective of path. Also for a global project, if a runtimePath is not explicitly specified then the directory where this index file is located becomes the runtimePath where the RevDeBug runtime is copied.
postPath
Path to the final output of the toolchain for postprocessing. Serves the same purpose for postFiles as path does for files.
postFiles
Wildcard specifiers of final output files for postprocessing.
Environment variables may be accessed in revdebug.json as such:
1
"mode": "${MODE}"
Copied!
These variables can also be passed in on the command line via the -a var=value or --arg var=value option. If you wish to use an environment variable or command line specified argument for an option which takes a number or boolean value then you must use a string:
1
"port": "${RECORD_PORT}"
Copied!
For more detailed configuration go to Advanced configuration.

Install RevDeBug NPM repository

Before compiling your project with RevDeBug you should have configured revdebug.json. Everything is done using the revd script. Depending on how you have the RevDeBug npm module installed you either execute it directly, or run it with npx revd. For a full list of options run revd --help.
First add reference to the @revdebug module repository:
1
npm config set @revdebug:registry https://nexus.revdebug.com/repository/npm/
Copied!
Or you can just set the repository for a single project by adding an .npmrc file with the line:
1
@revdebug:registry=https://nexus.revdebug.com/repository/npm/
Copied!
Then install as a local dependency:
1
npm install @revdebug/revdebug
Copied!
You can verify that RevDeBug is available by running node in interactive mode and doing:
1
> require('@revdebug/revdebug')
2
{}
Copied!
Instrument your project with RevDeBug:
1
> npx revd
Copied!

Advanced configuration

revd script is used to either compile individual groups of files or to compile from a revdebug.json configuration file that can be present in the topmost directory of the project. revdebug.json can contain only options, options and files for the project or multiple hierarchical subprojects with their own options each of which can be instrumented individually. Command line configuration options can override options in revdebug.json if you wish to build a subproject with different options than are specified in revdebug.json.
revd manages the source files you are instrumenting by copying the clean originals to a parallel directory tree under revdsrc/ at the top level directory of the project and replacing the original files with instrumented versions. This is done so that the original project does not have to be aware of or changed for RevDeBug.
The top level directory for the project is considered to be the first at or above the current level which contains a package.json or revdebug.json file. All operations are executed with respect to this directory, even if you run revd in a subdirectory.
For example, the following will instrument all the Javascript files in the current directory:
1
revd *.js
Copied!
For all Javascript files in all subdirectories as well:
1
revd "**/*.js"
Copied!
Note: The quotes are needed to prevent the shell from expanding the wildcards incorrectly on its own. Use quotes around wildcards whenever there is doubt.
If the previous commands are not run in the top project directory then an appropriate path configuration value will be set to make sure the compilation is relative to the top.
If project files are defined in revdebug.json then the project can be instrumented by doing: revd
And if multiple projects or subprojects are defined then they may be instrumented as follows:
1
revd .project1
Copied!
Or for a subproject of .project1:
1
revd .project1.subproject1
Copied!
Project names always start with a dot character and the alias for the top level project is just dot.

Compiler

In addition to being able to specify all project options on the command line, there are options which can only be passed on the command line in order to tell the compiler what to do or to control behavior, they are:
Actions:
​
--help
Print help info. (short: -h)
--version
Print the version. (short: -v)
--post
Do source map postprocessing after any tools farther down the chain have been run (typescript, webpack, etc...).
--clean
Restore original uninstrumented source files for given config or specified directly.
--remove
Restore ALL original source files in managed source directory and remove directory.
--dump
Dump processed configuration which would be used (don't actually do anything).
​
​
Behavior:
​
--arg ARG=VAL
Add argument for substitution in revdebug.json, "\${ARG}" will be replaced with "VAL". (short: -a)
-force
Force certain actions even if errors would otherwise prevent it. (short: -f)
--skip
Skip certain actions. (short: -s)
-j NUM
Maximum number of threads to use, Node 12+. (default: all logical CPUs)
--verbose
Show all error messages with stack traces. (short: --verb)
--chost ADDR
Compile-time record server override address to send metadata. (default: from --host or config)
--cport PORT
Compile-time record server override port to send metadata. (default: from --port or config)

revdebug.json file structure

The structure of the revdebug.json configuration file may be as follows (please note the names "option1", "option2" etc... used are just placeholders for the actual option names listed farther down):
1
{
2
"option1": option1,
3
"option2": option2,
4
...
5
}
6
​
Copied!
This is for a simple configuration which only specifies options, files would be specified on the command line. For a configuration which specifies what files to instrument:
1
{
2
"option1": option1,
3
"option2": option2,
4
...
5
"files": "files" or ["files", "more files", ...]
6
}
7
​
Copied!
You can even specify multiple hierarchical nested projects with their own options as:
1
{
2
"option1": option1, top-level options (inherited by subprojects),
3
"option2": option2,
4
...
5
".project1": {
6
"option1": option1, options here override parent
7
"option2": option2,
8
...
9
"files": "files" or ["files", "more files", ...]
10
},
11
".project2": {
12
"option1": option1, options here override parent
13
"option2": option2,
14
...
15
".subproject1": {
16
"option1": option1, options here override parent
17
"option2": option2,
18
...
19
"files": "files" or ["files", "more files", ...]
20
},
21
".subproject2": {
22
"option1": option1, options here override parent
23
"option2": option2,
24
...
25
"files": "files" or ["files", "more files", ...]
26
}
27
}
28
}
29
​
Copied!

List of options

The actual options are as follows:
Information:
​
Network:
​
host
The hostname or IP address as a string of the record server.
port
The port of the record server, this must be a number.
webPort
The port of the record server for web projects, this must be a number. A value of 0 indicates that the appropriate port 80 or 443 be used according to the secure status.
secure
Use secure connections.
connectTimeout
Timeout for connection attempt in milliseconds.
reconnectWait
Amount of time to wait before attempting reconnect after disconnect or failed connect in milliseconds.
Project:
​
solution
Solution name. If package.json is present this comes from the name field.
application
Application name. If package.json is present this comes from the main field.
version
The version string. If package.json is present this comes from the version field.
release
The release string, normally git commit hash (retrieved automatically if not provided).
authToken
RevDeBug authorization token.
​
​
Application Performance Monitoring:
​
apm
Enable or disable Application Performance Monitoring for project, can be true or false, default is false.
apmHost
Hostname of APM OAP server if different from record server host, the default is same as host. ("node" target only, ignored for "web")
apmPort
Port of APM OAP server, the default is 11800. ("node" target only, ignored for "web")
excludeIn
Single or list of HTTP status codes to exclude from generating error recordings on incoming requests. Since normally only codes between 400 and 599 generate error traces, it only really makes sense to exclude codes in this range. Status code 0 is a special code which represents errors which can not be determined at the time of filtering. This may represent a 500 internal server error or some other kind of error where the code was not available. For this reason this code was left apart to leave more granular control.
All these options can be specified on the command line to override any options in the revdebug.json file, so for example to set host on the command line specify --host address. Options which are boolean such as --apm or --sourceMap can be specified on the command line as such to indicate true or --noapm and --nosourceMap to indicate false, --apm=true and --apm=false are also accepted.
Previous
Data masking
Next
API
Last modified 1h ago
Copy link
Contents
Requirements
Configure RevDeBug.json with your project
Basic setup
Install RevDeBug NPM repository
Advanced configuration
Compiler
revdebug.json file structure
List of options