Skip to content

Nx/Nrwl

Older Versions of Nx/Nrwl (< v8.0.0)

If you are using a version of Nx/Nrwl prior to v8.0.0, then by default Wallaby’s automatic configuration will not work from root of your workspace. Without changes to your jest configuration files, Wallaby can only run for one application or library at a time. When you select your automatic configuration directory, you must select an application/library directory, and not the workspace root directory.

The reason that by default Wallaby.js is limited to only running on one project at a time is that the jest configuration files that are generated by Nx/Nrwl are not valid. That is to say, they cannot be run using npx jest or running jest from the CLI without some changes.

Your on-disk jest configuration files are augmented by @nrwl/jest when you run your tests with ng test. Additionally, the default jest configuration that is specified in the project root will also run your e2e tests, which will result in failures.

To run Wallaby on your entire project, you must ensure that npx jest runs correctly from your application and library root directories, and from your monorepo root directory. Once npx jest runs correctly, you may use Wallaby’s automatic configuration on your entire monorepo.

If jest does not run from the command-line for an application/library, you should be able to modify its jest.config.js to run by adding the following to its jest configuration:

...
  setupTestFrameworkScriptFile: './src/test-setup.ts',
  globals: {
    'ts-jest': {
      tsConfig: './tsconfig.spec.json',
      diagnostics: { warnOnly: true },
      stringifyContentPathRegex: '\\.html$',
      astTransformers: [
        'jest-preset-angular/build/InlineFilesTransformer',
        'jest-preset-angular/build/StripStylesTransformer'
      ]
    }
  }
...

Karma or Hybrid Test Frameworks

If your project has been configured to use different testing frameworks for different projects (e.g. karma and jest) then you must create a Wallaby configuration file for each testing framework. Wallaby cannot run for more than one testing framework at a time.

Our Angular CLI docs provide a good example for how to configure Wallaby with karma.

Chrome settings

When running tests in browser, wallaby.js uses your local version of Google Chrome (headless) as its test runner by default.

You may use an absolute or a relative path (or a command if you have it in PATH) in your wallaby.js config file. It may be useful if you would like to use a specific version of Chrome.

wallaby.js

module.exports = function () {
  return {
    ...


    env: {
      kind: 'chrome',
      runner: '/Users/user/path/to/chrome'
    }
  };
};

Passing Chrome flags

By default, wallaby.js is passing the following flags to Chrome:

  • --headless
  • --disable-gpu
  • --disable-translate
  • --disable-extensions
  • --disable-background-networking
  • --safebrowsing-disable-auto-update
  • --disable-sync
  • --metrics-recording-only
  • --disable-default-apps
  • --no-first-run

For Linux environments, an additional two flags are also passed:

  • --no-sandbox
  • --disable-setuid-sandbox

You may pass other flags, by using the env.params.runner setting, for example:

wallaby.js

module.exports = function () {
  return {
    ...


    env: {
      kind: 'chrome',
      params: {
        runner: '--headless --disable-gpu'
      }
    }
  };
};

Node settings

Node version

If you’d like to use your system default node.js version or any specific locally installed version instead of using the version configured for your IDE or editor, use the env.runner property to specify a command to invoke node or a path to a node executable.

module.exports = function () {
  return {
    ...
    env: {
      runner: 'node', // or full path to any node executable
    },
  };
};

Node flags

If you need to pass some node flags, such as --harmony, you may use env.params.runner property for that:

module.exports = function () {
  return {
    ...


    env: {
      params: {
        runner: '--harmony --harmony_arrow_functions',
      },
    },
  };
};

Environment variables

If you need to pass some process.env variables to the test environment, you may just set them right in the wallaby config file:

module.exports = function () {


  process.env.NODE_ENV = 'development';


  return {
    ...
  };
};

Alternatively, you may use env.params.env property for it:

module.exports = function () {
  return {
    ...


    env: {
      params: {
        env: 'NODE_PATH=/a/b/c;HOME=/Users/a/b',
      },
    },
  };
};

Node process reuse

When running your node.js tests, wallaby by default tries to re-use previously created node.js process(es) to make the runs faster. If you are relying on the test node process re-start for each run, because your tests are not cleaning after themselves (for example, they are not closing opened database connections, not stopping started web services, or are registering some callbacks that may be invoked after your test run finishes and interfere with your next test run), then you may use workers.restart setting set to true to make wallaby.js re-start node process for each run.

module.exports = function () {
  return {
    ...


    workers: {
      restart: true,
    },
  };
};

Whether you use the setting or not, you will still benefit from wallaby.js incremental test run feature compared to the normal test runner. However, while using the setting allows you to rely on the process re-start and avoid writing any cleanup code, we recommend that you consider adding clean-up code and not recycling node workers, as wallaby.js will be able to run your tests even faster if node processes are reusable.

Node process count

By default, wallaby.js automatically decides how many processes to use to run your tests in parallel based on your system capacity. However, sometimes you may need to manually set the number of workers to be used. For example, if your tests are creating an HTTP server that is listening on a certain port (as opposed to using dynamic port allocation for your tests), you may need to set the workers count to 1, because otherwise you may have issues with different test workers trying to create the server on the same port.

module.exports = function () {
  return {
    ...




    workers: {
      initial: 1,
      regular: 1,
    },
  };
};

A better approach would be to dynamically allocate ports, so that your tests could run in parallel.

Troubleshooting

If you get stuck or something isn’t working for you, you may find a similar solved issue in our github issues repository. If you can’t find a solution, create a new issue.