Skip to main content
Version: 3.x

Project Configuration: Dev, Test, Build

Babel​

Out of the box Redwood configures Babel so that you can write modern JavaScript and TypeScript without needing to worry about transpilation at all. GraphQL tags, JSX, SVG imports—all of it's handled for you.

For those well-versed in Babel config, you can find Redwood's in @redwoodjs/internal.

Configuring Babel​

For most projects, you won't need to configure Babel at all, but if you need to you can configure each side (web, api) individually using side-specific babel.config.js files.

Heads up

.babelrc{.js} files are ignored. You have to put your custom config in the appropriate side's babel.config.js: web/babel.config.js for web and api/babel.config.js for api.

Let's go over an example.

Example: Adding Emotion​

Let's say we want to add the styling library emotion, which requires adding a Babel plugin.

  1. Create a babel.config.js file in web:
touch web/babel.config.js

  1. Add the @emotion/babel-plugin as a dependency:
yarn workspace web add --dev @emotion/babel-plugin

  1. Add the plugin to web/babel.config.js:
web/babel.config.js
module.exports = {
  plugins: ["@emotion"] // 👈 add the emotion plugin
}

// ℹ️ Notice how we don't need the `extends` property

That's it! Now your custom web-side Babel config will be merged with Redwood's.

Jest​

Redwood uses Jest for testing. Let's take a peek at how it's all configured.

At the root of your project is jest.config.js. It should look like this:

jest.config.js
module.exports = {
  rootDir: '.',
  projects: ['<rootDir>/{*,!(node_modules)/**/}/jest.config.js'],
}

This just tells Jest that the actual config files sit in each side, allowing Jest to pick up the individual settings for each. rootDir also makes sure that if you're running Jest with the --collectCoverage flag, it'll produce the report in the root directory.

Web Jest Config​

The web side's configuration sits in ./web/jest.config.js

const config = {
  rootDir: '../',
  preset: '@redwoodjs/testing/config/jest/web',
  // ☝️ load the built-in Redwood Jest configuration
}

module.exports = config

You can always see Redwood's latest configuration templates in the create-redwood-app package.

The preset includes all the setup required to test everything that's going on in web: rendering React components and transforming JSX, automatically mocking Cells, transpiling with Babel, mocking the Router and the GraphQL client—the list goes on! You can find all the details in the source.

Api Side Config​

The api side is configured similarly, with the configuration sitting in ./api/jest.config.js. But the api preset is slightly different in that:

  • it's configured to run tests serially (because Scenarios seed your test database)
  • it has setup code to make sure your database is 1) seeded before running tests 2) reset between Scenarios

You can find all the details in the source.

GraphQL Codegen​

You can customize the types that Redwood generates from your project too! This is documented in a bit more detail in the Generated Types doc.

Debugger configuration​

The yarn rw dev command is configured by default to launch a debugger on the port 18911, your Redwood app also ships with default configuration to attach a debugger from VSCode.

Simply run your dev server, then attach the debugger from the "run and debug" panel. Quick demo below:


ℹ️ Tip: Can't see the "Attach debugger" configuration? In VSCode

You can grab the latest launch.json from the Redwood template here. Copy the contents into your project's .vscode/launch.json

Customizing the debug port​

You can choose to use a different debug port in one of two ways:

a) Using the redwood.toml

Add/change the debugPort under your api settings

redwood.toml
[web]
  # .
  # .
[api]
  port = 8911
  debugPort = 18911 # 👈 change me!

If you set it to false, no debug port will be exposed. The debugPort is only ever used during development when running yarn rw dev

b) Pass a flag to rw dev command

You can also pass a flag when you launch your dev servers, for example:

yarn rw dev --debugPort 75028

The flag passed in the CLI will always take precedence over your setting in the redwood.toml

Just remember to also change the port you are attaching to in your ./vscode/launch.json

Ignoring the .yarn folder​

The .yarn folder contains the most recent Yarn executable that Redwood supports which is the recommended way to ensure things run smoothly for everyone. From VSCode's perspective, this of course is just another folder containing code, so it will

  1. include its contents in project-wide, full-text searches
  2. display it in the file browser
  3. watch its contents for changes

… which, depending on your personal preference, is something you may not need or want.

Fortunately, all these aspects are configurable via VSCode's settings.json. You have the choice of making these changes to your local Redwood project's configuration found in .vscode/settings.json or globally (so they apply to other projects as well). For global changes, hit F1 or Ctrl+Shift+P (that's ⌘+Shift+P if you're on Mac) and search for "Preferences: Open User Settings (JSON)".

Note that the local workspace configuration always overrules your user settings. The VSCode website provides an extensive explanation on how its config inheritance works. It also has a complete reference of all available settings and their defaults.

Excluding a folder from search results only​

Adding the following would exclude any .yarn folder encountered anywhere in the project (that's what the ** glob pattern does) from search results:

  "search.exclude": {
    "**/.yarn": true
  }

Excluding a folder from the file browser and searching​

  "files.exclude": {
    "**/.yarn": true
  }

This setting also excludes all matching folders and files from search results, so there's no point in adding a search.exclude setting separately.

Don't worry: this setting won't influence change detection in your "Source Control" tab—that would be managed via .gitignore.

Excluding a folder from watching​

  "files.watcherExclude": {
    "**/.yarn": true
  }

This setting works independently of the ones above and so it needs to be added separately. It's important to note that files or folders matched by this setting will no longer immediately appear (or disappear):

  • from existing search results (but as soon as you search again or change the search term, they'll be discovered)
  • in your "Source Control" tab, unless you hit the "Refresh" button

Admittedly, the .yarn folder won't change that often, so this may not be the best example. But we thought we'd share this technique with you so that you'd know how to apply it to any folders that you know change very often, and how to tell VSCode not to bother wasting any CPU cycles on them.