Skip to main content
Version: Canary

Project Configuration: Dev, Test, Build

Babel​

Out of the box Cedar compiles your modern JavaScript and TypeScript without you 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 Cedar's in @cedarjs/babel-config.

Configuring Babel​

For most projects, you won't need to configure Babel at all. When you do, the two sides are configured differently:

  • api: put your config in api/babel.config.js. Cedar merges it with its own api-side config when it builds your api side (yarn cedar build, yarn cedar dev and the Vite-based api pipeline).
  • web: Vite doesn't apply web/babel.config.js. Pass custom plugins and presets through the cedar() Vite plugin's babel option instead, see Custom Babel plugins.

Heads up

.babelrc{.js} files are ignored. Api-side config has to live in api/babel.config.js.

Installing Babel for the api side​

Cedar itself doesn't need Babel to build your api side, so @cedarjs/babel-config treats @babel/core and @babel/preset-typescript as optional peer dependencies and doesn't install them for you. An api/babel.config.js is only applied when both packages are installed in your api workspace. Cedar's api-side config is written for Babel 7, so pin that major:

yarn workspace api add -D @babel/core@^7 @babel/preset-typescript@^7

If api/babel.config.js exists but either package is missing, the api build fails with an error telling you to run that command.

Example: Removing console calls on the api side​

Let's say we want to strip console.* calls from the api side using babel-plugin-transform-remove-console.

  1. Install Babel and the plugin in the api workspace:
yarn workspace api add -D @babel/core@^7 @babel/preset-typescript@^7 babel-plugin-transform-remove-console

  1. Create api/babel.config.js and add the plugin:
api/babel.config.js
export default {
  plugins: ['transform-remove-console'], // 👈 add the plugin
}

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

That's it! Your custom api-side Babel config is merged with Cedar's.

Vitest​

Cedar uses Vitest for testing. Let's take a peek at how it's all configured.

At the root of your project is vitest.config.ts. It should look like this:

vitest.config.ts
import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    projects: ['<rootDir>/{*,packages/*}/vite?(st).config.{js,ts}'],
  },
})

This just tells Vitest that the actual config files sit in each side (and in any workspace packages you've generated), allowing Vitest to pick up the individual settings for each.

Web Vitest Config​

The web side's test configuration is part of ./web/vite.config.ts

/// <reference types="vitest/config" />

import { defineConfig } from 'vite'

import { cedar } from '@cedarjs/vite'

export default defineConfig(({ mode }) => ({
  plugins: [cedar({ mode })],
  test: {
    environment: 'jsdom',
    setupFiles: ['./vitest.setup.ts'],
    globals: true,
  },
}))

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

The cedar() Vite plugin together with web/vitest.setup.ts includes all the setup required to test everything that's going on in web: rendering React components and transforming JSX, automatically mocking Cells, mocking the Router and the GraphQL client—the list goes on!

Api Side Config​

The api side is configured in ./api/vitest.config.ts.

import { defineConfig } from 'vitest/config'

import { cedarVitestPreset } from '@cedarjs/vite/api'

export default defineConfig({
  plugins: [cedarVitestPreset()],
  test: {
    globals: true,
  },
})

The api preset is slightly different from the web side 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

GraphQL Codegen​

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

Debug configurations​

Dev Server​

The yarn cedar dev command is configured by default to open a browser and a debugger on the port 18911 and your redwood app ships with several default configurations to debug with VSCode.

Customizing the configuration​

a) Using the cedar.toml

Add/change the debugPort or open under your api settings

cedar.toml
[web]
  # .
[api]
  # .
  debugPort = 18911 # change me!
[browser]
  open = true # change me!

b) Pass a flag to cedar dev command

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

yarn cedar dev --debugPort 75028

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

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

API and Web Debuggers​

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

Compound Debugger​

The compound configuration is a combination of the dev, api and web configurations. It allows you to start all debugging configurations at once, facilitating simultaneous debugging of server and client-side code.


ℹ️ Tip: Can't see the debug configurations? In VSCode

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

Ignoring the .yarn folder​

The .yarn folder contains the most recent Yarn executable that Cedar 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 Cedar 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.

Trailing whitespace​

If you're using VS Code, or another editor that supports EditorConfig, trailing whitespace will be trimmed in source files, but preserved in html, markdown and mjml files when saving.

This behavior is controlled by .vscode/settings or .editorconfig depending on your editor.

In JavaScript and TypeScript files trailing whitespace has no significance, but for html, markdown and mjml it does. That's why the behavior is different for those files. If you don't like the default behavior Cedar has configured for you, you're free to change the settings in those two files.