Skip to content

Releases: cedarjs/cedar

v2.3.0

02 Jan 13:24
@Tobbe Tobbe
v2.3.0
81e4cee

Choose a tag to compare

View all tags
v2.3.0

Release Notes

We have two new exciting features in this release!

  1. Custom Cedar scripts templates
  2. (Experimental) code sharing between the web and api sides

1. Custom Cedar scripts templates

Many might not be aware of this, but you can customize most of the code that Cedar's generators generate for you. The generated code is all based on templates, and you can bring your own templates for all the generator commands. If you for example don't like the default page that yarn cedar generate page gives you, you can update the template for generated pages.

Up until now there was one thing missing though – being able to customize the template for scripts generated by yarn cedar generate script. But no more! As of this release you can run yarn setup generator script and you will get generatorTemplates/scripts/script/script.ts.template, which is the template that's used for new scripts. Make whatever edits you want, and the next time you generate a script your own custom template will be used!

To make this work I decided to move all generated templates to this new generatorTemplates/ top level directory. So if you have custom templates for any of the generators already, please move them to this new top level directory. web/generators/<generator-name> should be moved to generatorTemplates/web/<generator-name>, and same thing for api side generators. This release also includes a codemod you can run to do this for you. If you want to automatically move your existing templates you can run npx @cedarjs/codemods@latest move-generator-templates. The old location continues to work, so moving your existing templates is optional, but highly recommended. I plan to remove support for the old location in the next major release of Cedar.

Do be aware though that you're basically "ejecting" here. If there are any updates/fixes to the templates Cedar uses you won't get those. Cedar will continue using your templates.

TL;DR:

  • Run npx @cedarjs/codemods@latest move-generator-templates.
  • Generate templates for scripts by running yarn cedar setup generator script.

2. Code Sharing Between the Web and Api Sides

Being able to share code between the web and api sides of a Cedar app has been a long standing feature request. I have now implemented experimental support for this by the way of workspace packages.

It works, but the workflow is still too manual for the feature to be generally available.

Read more in the PR description for #767 and #908 and see the list of things still left to do in #725

To make code sharing work you need to update the tsconfig file for the API side. The new yarn cedar generate package command will do this for you, so no manual update is strictly needed. But it's recommended to also update the tsconfig file in the scripts/ directory, and the package generator command will not do this. New Cedar apps will have updated tsconfig files for both api/ and scripts/, but for existing apps we recommend you manually update. The required change is to upgrade "module" to "node20". See more in #902

And, of course, in alignment with feature highlight #1 above, it's also possible to fully customize the templates used for generating workspace packages. Just run yarn cedar setup generator package and you'll get to customize all the templates you want in generatorTemplates/packages/package.

Because this is an experimental feature you have to manually enable it like this in your redwood.toml file:

[experimental.packagesWorkspace]
  enabled = true

TL;DR: Run yarn cedar generate package and follow the instructions on the screen.

Changelog

🚀 Features

feat(upgrade): Add first upgrade script (#857) by @Tobbe

Adding a script to show a deprecation warning if old workspace syntax is detected

feat(cli): Link to Proxy docs on failed latestVersion call (#889) by @Tobbe

Got this error report on Discord earlier today

yarn cedar upgrade
√ Confirm upgrade
× Could not find the latest version
■ Removing CLI cache
■ Running yarn install
■ Refreshing the Prisma client
■ De-duplicating dependencies
■ One more thing..
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Error: Could not find the latest version
    at setLatestVersionToContext (file:///project_path/node_modules/@cedarjs/cli/dist/commands/upgrade.js:249:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
    at async _Task.run (file:///project_path/node_modules/listr2/dist/index.js:1979:11)

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Need help?
 - Not sure about something or need advice? Reach out on our Forum
 - Think you've found a bug? Open an issue on our GitHub
 - Here's your unique error reference to quote: '8a23ea7e-157a-4555-bbb7-f0f7b846bef3'

After some debugging we discovered this:

e TypeError: fetch failed
    at node:internal/deps/undici/undici:15845:13
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
    at async function_ (file:///D:/dimas/project/re-BISA/node_modules/ky/distribution/core/Ky.js:23:28)
    at async #retry (file:///D:/dimas/project/re-BISA/node_modules/ky/distribution/core/Ky.js:286:20)
    at async result.<computed> [as json] (file:///D:/dimas/project/re-BISA/node_modules/ky/distribution/core/Ky.js:89:34)
    at async packageJson (file:///D:/dimas/project/re-BISA/node_modules/package-json/index.js:43:10)
    at async latestVersion (file:///D:/dimas/project/re-BISA/node_modules/latest-version/index.js:6:20)
    at async setLatestVersionToContext (file:///D:/dimas/project/re-BISA/node_modules/@cedarjs/cli/dist/commands/upgrade.js:239:26)
    at async _Task.run (file:///D:/dimas/project/re-BISA/node_modules/listr2/dist/index.js:1979:11) {
  [cause]: Error: getaddrinfo ENOTFOUND registry.npmjs.org
      at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:122:26) {
    errno: -3008,
    code: 'ENOTFOUND',
    syscall: 'getaddrinfo',
    hostname: 'registry.npmjs.org'
  }
}

And with some more digging we saw this:

node -e "require('dns').lookup('registry.npmjs.org', console.log)"
Error: getaddrinfo ENOTFOUND registry.npmjs.org
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:111:26) {
  errno: -3008,
  code: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'registry.npmjs.org'
}

At which point we realized that the user was behind a Proxy and needed to configure the proxy to be able to access the npm registry. They had already configured yarn and npm to use their proxy, but not Node.

When I found the docs for the recently added proxy support natively in Node they were able to set some env vars and could then successfully run the upgrade command.

I decided I should update the error message that yarn cedar upgrade prints to include the https://nodejs.org/api/http.html#built-in-proxy-support link.
And I also made it print the full error message when you use the --verbose flag.

feat(cli): Experimental flag to enable shared packages (#908) by @Tobbe

Sharing code by putting it in a workspace package and importing it on both the web and api sides now work, but the feature isn't polished enough for general availability yet. But I still want users to be able to experiment with this new feature, so I'm putting it behind an experimental flag.

Just add this to your redwood.toml file to enable the feature

[experimental.packagesWorkspace]
  enabled = true
feat(cli): Custom script templates (#813) by @Tobbe

Not a lot of people know this, but it's possible to fully customize the files being generated by Cedar generators like yarn cedar generate page, yarn cedar generate scaffold etc.

The script generator however (yarn cedar generate script <name>) did not have this possibility. But now it does!

To facilitate this improvement I've also decided to move the templates the generators use. Templates for generators used on the web side, like yarn cedar generate page used to live inside web/generators/. And for api side generators there were a api/generators/ folder (if you had custom generators setup that is).

For scripts I didn't want to have a scripts/generators/ folder though. Because that might interfere with a script you already have, or wanted to create in the future.

So with this PR I move all generator templates out into a new top-level folder called generatorTemplates/. Inside that folder you'll have api/, web/ and scripts/ sub-folders.

If you don't have any custom templates the folder(s) won't be created.

This used to be a breaking change, but thanks to #876 I can now release this in a minor version if I release both PRs together (which I will)

📝 For the release notes: There's also a codemod for this upgrade that will move your current custom templates for you

feat(upgrade-scripts): 3.x upgrade script and updated canary script (66c457c) by @Tobbe

Adding a package.json file to make it easier to test the scripts locally without Node complaining about ESM syntax

feat(cca): Update tsconfig and jsconfig to support require(ESM) (#902) by @Tobbe

Update tsconfig and jsconfig for the api side and for scripts to align with the fact that we now require Node 24. This lets TS know that it's safe to requ...

Read more

Contributors

Tobbe and renovate-bot
Loading

v2.2.1

29 Dec 14:39
@Tobbe Tobbe
v2.2.1
b29eb5f

Choose a tag to compare

View all tags
v2.2.1 Latest
Latest

Release Notes

This release contains fixes to the pre-upgrade command feature that was introduced in v2.2.0. I hope to make use of that feature in the next minor and major releases, so you need to install this patch release first, to be able to take advantage of the extra help the pre-upgrade script will give you.

Changelog

🛠️ Fixes

fix(cli): Fix mailer setup on Windows (#850) by @Tobbe

Adding this to debug #830
And I'm probably going to keep it, to make sure we're not regressing on this in the future

fix(upgrade): canary pre-upgrade scripts (#858) by @Tobbe

Fix pre-release scripts for tag releases like canary and rc

fix(upgrade): Tweak output from pre-upgrade scripts (#861) by @Tobbe
  • Error emoji that works in more terminals (🚨)
  • Two spaces for indentation
  • Only one empty line between heading and messages
  • Extra details on errors with --verbose
fix(upgrade): Tweak output for package upgrades and pre-upgrade scripts (#872) by @Tobbe

Before:

Updated packages appears at end of output
Pre-upgrade message title icon 📣 is indented 3 spaces

image

After:

Updated packages are grouped with the correct task in the task list
Pre-upgrade message title icon is correctly indented 2 spaces

image
fix(upgrade): Use npm with pre-upgrade scripts (#859) by @Tobbe

Switch from yarn to npm to not have to worry about PnP support, yarn versions, etc. npm is guaranteed to be available on all systems with Node, and we know it's a modern version of npm too.

And to not have to fiddle with updating a package.json file to tell Node to use ESM mode I set the file extension to .mts.

📦 Dependencies

Click to see all 13 dependency updates

🧹 Chore

Click to see all chore contributions
  • chore(renovate): Finer grained control for some packages (node, uuid, kill-port) (#867) by @Tobbe
  • chore(cli): Convert JS files to TS (part I) (#855) by @Tobbe
  • chore(config): migrate Renovate config (#868) by @renovate-bot

Contributors

Tobbe and renovate-bot
Assets 2
Loading

v2.2.0

26 Dec 16:37
@Tobbe Tobbe
v2.2.0
aa9d918

Choose a tag to compare

View all tags
v2.2.0

Release Notes

The focus of this release has been to get all minor and patch version updates to packages Cedar depend on merged. And I'm happy to say I succeeded! This release has 77 commits with package updates.

On the Features front there are two things I want to call out

  1. I've updated the templates for new Cedar apps to use modern workspace config in the root package.json file. I recommend you do the same for your projects.

    Just change it from this:

      "workspaces": {
    "packages": [
      "api",
      "web"
    ]
  },

    to this:

      "workspaces": [
    "api",
    "web"
  ]

    Read more here: #751

  2. The yarn cedar upgrade cli now comes with a new feature where it can run pre-upgrade scripts and print messages relevant to the new release you're about to upgrade to. There's a bit of a chicken-and-egg problem here though, where you need a version of the cli that already has this support before it can help you with the upgrade to the next version. So I'm shipping this feature with this version without any actual pre-upgrade scripts, so that all users get the new cli feature for when it's needed for future upgrades.

    Future upgrades might for example have a pre-check to make sure you've updated to the new workspace definition syntax shown above before it lets you continue with the upgrade (unless you use --force).

There's also a "fix" worth mentioning: For those of you who work on the framework itself I've renamed the rwfw binary to cfw. Piece by piece I'm chipping away on the Redwood to Cedar rebranding 🙂

Changelog

🚀 Features

feat(cca): Use modern workspace config (#751) by @Tobbe

Cedar apps have always shipped with the following workspace config

  "workspaces": {
    "packages": [
      "api",
      "web"
    ]
  },

If you read yarn's docs on workspaces they say the "workspaces" value should be an array, but here it was an object.
It's very difficult to find any kind of documentation for this object notation. Even going back to the yarn v1.x docs it says it should be an array.
Here are their introduction blog post when they added workspaces support: https://classic.yarnpkg.com/blog/2017/08/02/introducing-workspaces/
That blog post also only mentions the array syntax.

Even more digging lead me to this blog post from 2018 https://classic.yarnpkg.com/blog/2018/02/15/nohoist/
Yarn introduced a nohoist option for workspaces. And this is where they also added support for workspaces being an object with a packages key.

So, from yarn v1.4.2 workspaces could be an object.

With yarn v2 the hoisted option in the workspaces config was replaced by their nmHoistingLimits config as seen in their migration docs. But, and this is only my guess, they decided to keep support for the workspaces.packages syntax to be less disruptive and make it easier for projects to upgrade.

So the reason we use the object notation is that the template in Redwood was set up to use that syntax when Redwood still used yarn v1 >v1.4 and it just hasn't changed since then. This is where Redwood introduced that config: redwoodjs/create-redwood-app@3651cb0

Switching to the array syntax also make the config work with npm and pnpm, making it easier for users to switch to another package manager if they want.

feat(cli): pre-upgrade scripts (#833) by @Tobbe

This PR adds a new feature to the yarn cedar upgrade command where it can download and execute a script before running the actual upgrade.

This is intended to be used to either just print informational messages during upgrade, or to run pre-upgrade checks. If, for example, there is something the user has to change in the project before being able to upgrade, this would be a good place to check if that thing has been completed

feat(cli): Better upgrade and exit output (#839) by @Tobbe

This PR improves cli command output for the upgrade command specifically and the error display for all cli commands in general.

The upgrade command has update information displayed inline instead of at the end of the command output.

Error output has been updated to link to the Cedar Discord instead of the RW forums. And error delimiter lines have been shortened to prevent wrapping when the output is long enough to cause scrollbars to render.

Before

dry-run

image

error

image

After

dry-run

image

error

image

🛠️ Fixes

fix(cedar): Update all docs links to point to https://cedarjs.com/docs (#783) by @Tobbe

Update all old rw doc links to now point to https://cedarjs.com/docs instead

fix(bin): Rename rwfw to cfw (#793) by @Tobbe

Renaming the rwfw that's used for internal framework development and testing to cfw.
This could be considered a breaking change, but since it's only(?) used by maintainers and contributors, not Cedar app developers, I'll release this as part of the next minor version

Also renaming a few internal environment variable names and const names.

📦 Dependencies

Click to see all 77 dependency updates
Read more

Contributors

Tobbe and renovate-bot
Loading

v2.1.1

19 Dec 11:42
@Tobbe Tobbe
v2.1.1
a24d2c1

Choose a tag to compare

View all tags
v2.1.1

Release Notes

This release makes the switch to eslint's flat config introduce fewer eslint rule changes. The goal is that no new errors/warnings should be introduced to your codebase. Please file an issue if you see something new.

Changelog

🛠️ Fixes

fix(eslint): Make new flat config more compatible with the old legacy config (#730) by @Tobbe

A user reported seeing new eslint errors after upgrading to Cedar v2

/home/me/dev/project/web/src/test-helpers.ts
  165:3  error  'mockGraphQLQuery' is not defined  no-undef

/home/me/dev/project/web/src/test/helpers.ts
  30:3  error  'mockCurrentUser' is not defined  no-undef

  68:4   error  'GraphQLMutationHookOptions' is not defined  no-undef
  68:36  error  'GraphQLOperationVariables' is not defined   no-undef

This PR addresses those issues, and a few more I noticed while working on the config

📦 Dependencies

Click to see all 27 dependency updates

🧹 Chore

Click to see all chore contributions
  • chore(ci): Add GitHub stale action. Mark issues and PRs as stale after 30 days (3384169) by @Tobbe
  • chore(ci): Fix permissions and message for Stale action (9652dc7) by @Tobbe
  • chore(jobs): Fix timing issue in flaky forever loop unit test by mocking timers (#739) by @Tobbe

Contributors

Tobbe and renovate-bot
Loading

v2.1.0

15 Dec 21:58
@Tobbe Tobbe
v2.1.0
d65fecb

Choose a tag to compare

View all tags
v2.1.0

Release Notes

This is an exciting release! Cedar is using eslint v8, which has reached end-of-life. This release moves to eslint's new flat config format in preparation of upgrading to eslint v9 in a future major version.

This is a non-breaking release, because you can still use the old eslint config format, but I have marked it deprecated to encourage everyone to switch over to the flat config format in preparation of eslint v9.

eslint Flat Config Migration Guide for Existing Apps

If you have an existing Cedar app using the old .eslintrc.js or package.json eslintConfig, follow these steps to migrate:

  1. Create a new flat config file in your project root:

    // eslint.config.mjs
import cedarConfig from '@cedarjs/eslint-config'

export default await cedarConfig()

  2. Migrate custom rules: If you had custom rules in your old config, add them to your new flat config:

    export default [
  ...(await cedarConfig()),
  {
    rules: {
      // Your custom rules here
    },
  },
]

  3. Remove old config:

    • Delete .eslintrc.js if it exists
    • Remove eslintConfig field from package.json if it exists

That's it! Your linting should work the same as before.

eslint has a general flat-config migration guide here: https://eslint.org/docs/latest/use/configure/migration-guide
Please read their guide if you have custom config

If you don't want to migrate now, and get too annoyed by the deprecation message, you can disable it by setting eslintLegacyConfigWarning to false in your redwood.toml file

Changelog

🚀 Features

feat(cli): cedar upgrade command: Skip confirmation if tag is provided (#672) by @Tobbe

If the user has passed a tag to upgrade to I now assume they know what they're doing and that they actually want to upgrade. Therefore I skip the confirmation prompt

feat(cli): Show deprecation message for legacy eslint configs (#651) by @Tobbe

Follow-up on #629. That PR switched the entire framework, and project templates, over to eslint's new flat config. This PR adds a deprecation notice that's printed whenever someone runs yarn cedar lint that is still using the legacy config format.

The deprecation warning can be disabled by setting eslintLegacyConfigWarning to false in your redwood.toml file

feat(eslint): Migrate to eslint's new flat config format (#629) by @Tobbe

The old config format is still supported, but migrating to flat config is highly recommended. I will soon also upgrade to eslint v9, and at that point I will not support the old eslint config format anymore.

Migration Guide for Existing Apps

If you have an existing Cedar app using the old .eslintrc.js or package.json eslintConfig, follow these steps to migrate:

  1. Create a new flat config file in your project root:

    // eslint.config.mjs
import cedarConfig from '@cedarjs/eslint-config'

export default await cedarConfig()

  2. Migrate custom rules: If you had custom rules in your old config, add them to your new flat config:

    export default [
  ...(await cedarConfig()),
  {
    rules: {
      // Your custom rules here
    },
  },
]

  3. Remove old config:

    • Delete .eslintrc.js if it exists
    • Remove eslintConfig field from package.json if it exists

That's it! Your linting should work the same as before.

Type-Aware Linting

Cedar itself uses type-aware linting. But it's not enabled by default for Cedar apps.
If you want to have type-aware linting in your app, this is how you can enable it

// eslint.config.mjs
import cedarConfig from '@cedarjs/eslint-config'
import tseslint from 'typescript-eslint'

export default tseslint.config(
  ...(await cedarConfig()),
  // Override TypeScript config with type-checked rules
  {
    files: ['**/*.ts', '**/*.tsx'],
    extends: [
      ...tseslint.configs.recommendedTypeChecked,
      ...tseslint.configs.stylisticTypeChecked,
    ],
    languageOptions: {
      parserOptions: {
        project: './tsconfig.json', // or './tsconfig.eslint.json'
        tsconfigRootDir: import.meta.dirname,
      },
    },
    rules: {
      // Can override specific type-checked rules here
      '@typescript-eslint/no-unsafe-assignment': 'warn',
      '@typescript-eslint/no-unsafe-member-access': 'warn',
      // etc.
    },
  },
)

📚 Docs

docs(fix): Code blocks formatting and syntax fix (#703) by @Tobbe

I tried to upgrade https://github.com/JoshuaKGoldberg/prettier-plugin-curly to v0.4.1 but couldn't, because it was too aggressive in how it wanted to format our docs (see JoshuaKGoldberg/prettier-plugin-curly#898). But some of the files it changed I liked, and it even actually found a syntax bug in one of the code examples!

This PR addes the changes I wanted from the prettier-plugin-curly upgrade, without actually upgrading the plugin

📦 Dependencies

Click to see all 23 dependency updates

🧹 Chore

Click to see all chore contributions
  • chore(cli): Silence flightcontrol test (956d90c) by @Tobbe
  • chore(ci): Update test-project fixture (7d2421a) by @Tobbe
  • chore(package.json): Fix bad merge of #699. Lost changes to resorted scripts (719ff85) by @Tobbe
  • Version docs to 2.1 (2dbf57d) by @Tobbe
  • chore(cli): Fix silencing of console.log in flightcontrol test (#701) by @Tobbe
  • chore(jobs): Fix timing issue in flaky forever loop unit test (#704) by @Tobbe
  • chore(ci): Skip tests that'd fail on unreleased package versions during release (#710) by @Tobbe

Contributors

Tobbe and renovate-bot
Loading

v2.0.3

15 Dec 09:25
@Tobbe Tobbe
v2.0.3
f9d8607

Choose a tag to compare

View all tags
v2.0.3

Release Notes

This release is mainly created because of the recent React CVEs.

For Cedar's experimental RSC support we were using a version of react-server-dom-webpack that was vulnerable to https://www.cve.org/CVERecord?id=CVE-2025-55182 (more info on the CVE here: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components)

RSC support in Cedar was only ever available in @canary releases, and only if you had the experimental support turned on in your redwood.toml. Stable version releases of Cedar, like v1.1.1 and v2.0.2 etc did still have react-server-dom-webpack as a dependency, but it was not used in a way that would make Cedar vulnerable to the exploit detailed in the CVE

So, regular Cedar apps were not affected. But some code security scanners still flagged Cedar apps because of the (at runtime unused) dependency towards react-server-dom-webpack. That dependency has now been updated to the latest version, which fixes all the known CVEs.

Changelog

🛠️ Fixes

fix(history): Unique listener IDs (#686) by @Tobbe

When two history listeners were created in quick succession they could end up with the same ID, which would lead to one listener overwriting the other.

I now generate random IDs, so that collisions don't happen.

📚 Docs

  • docs(upgrade): Move RW->Cedar migration instructions to docs/ (d213402) by @Tobbe
  • docs(README): Link to RW->Cedar migration docs (76d27b2) by @Tobbe
  • docs(upgrade): Fix headings in rw->cedar docs (15aeeec) by @Tobbe
  • docs(redirect): /docs/8.6 -> /docs/8.x (5ddc6c0) by @Tobbe
  • docs(rw-to-cedar): Point out that latest RW-compatible version is v1.x (#669) by @Tobbe

📦 Dependencies

Click to see all 60 dependency updates
fix(deps): Upgrade to React 19.0.1 in canary builds (#653) by @Tobbe

For the experimental RSC support Cedar was using a version of react-server-dom-webpack that was vulnerable to https://www.cve.org/CVERecord?id=CVE-2025-55182 (more info on the CVE here: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components)

RSC support in Cedar was only ever available in @canary releases, and only if you had the experimental support turned on in your redwood.toml. Stable version releases of Cedar, like v1.1.1 and v2.0.2 etc did still have react-server-dom-webpack as a dependency, but it was not used in a way that would make Cedar vulnerable to the exploit detailed in the CVE

Dev notes for this PR:

I was getting this error after upgrading the React version

🔻 Caught error outside shell
TypeError: Cannot read properties of undefined (reading 'moduleMap')
    at createResponseFromOptions (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood-rsc-project/2025-12-10T08-28-32.700Z/web/dist/ssr/assets/client.edge-C5BWVTc4.mjs:1316:36)
    at reactServerDomWebpackClient_edge_production.createFromReadableStream (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood-rsc-project/2025-12-10T08-28-32.700Z/web/dist/ssr/assets/client.edge-C5BWVTc4.mjs:1389:13)
    at renderRoutesSsr (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood-rsc-project/2025-12-10T08-28-32.700Z/web/dist/ssr/assets/Routes-WMeu0MyQ.mjs:20617:16)
🔻 Failed to render shell
TypeError: Cannot read properties of undefined (reading 'moduleMap')
    at createResponseFromOptions (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood-rsc-project/2025-12-10T08-28-32.700Z/web/dist/ssr/assets/client.edge-C5BWVTc4.mjs:1316:36)
    at reactServerDomWebpackClient_edge_production.createFromReadableStream (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood-rsc-project/2025-12-10T08-28-32.700Z/web/dist/ssr/assets/client.edge-C5BWVTc4.mjs:1389:13)
    at renderRoutesSsr (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood-rsc-project/2025-12-10T08-28-32.700Z/web/dist/ssr/assets/Routes-WMeu0MyQ.mjs:20617:16)

After some googling I found this PR: facebook/react#31299

The fix was pretty straightforward after looking at the diff of that PR

When that was fixed, I got this error instead:

🔻 Caught error outside shell
Error: Could not find the module "/private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood/test-project-rsa/2025-12-10T08-45-35.802Z/web/dist/rsc/assets/rsa-chat.ts-0.mjs#onSend" in the React Server Manifest. This is probably a bug in the React Server Components bundler.
    at resolveServerReference (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood/test-project-rsa/2025-12-10T08-45-35.802Z/web/dist/ssr/assets/client.edge-GG1I0Rjr.mjs:58:13)
    at loadServerReference (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood/test-project-rsa/2025-12-10T08-45-35.802Z/web/dist/ssr/assets/client.edge-GG1I0Rjr.mjs:743:25)
    at getOutlinedModel (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood/test-project-rsa/2025-12-10T08-45-35.802Z/web/dist/ssr/assets/client.edge-GG1I0Rjr.mjs:820:14)
    at parseModelString (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood/test-project-rsa/2025-12-10T08-45-35.802Z/web/dist/ssr/assets/client.edge-GG1I0Rjr.mjs:878:40)
    at Object.<anonymous> (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood/test-project-rsa/2025-12-10T08-45-35.802Z/web/dist/ssr/assets/client.edge-GG1I0Rjr.mjs:1288:14)
    at JSON.parse (<anonymous>)
    at initializeModelChunk (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood/test-project-rsa/2025-12-10T08-45-35.802Z/web/dist/ssr/assets/client.edge-GG1I0Rjr.mjs:649:22)
    at ReactPromise.then (file:///private/var/folders/7j/9p56mwmj6jsfdr2h5_884j9w0000gn/T/redwood/test-project...
Read more

Contributors

Tobbe and renovate-bot
Loading

v2.0.2

30 Nov 15:41
@Tobbe Tobbe
v2.0.2
693272a

Choose a tag to compare

View all tags
v2.0.2

Changelog

api side CJS/ESM bug

Fixing a CJS/ESM issue with @cedarjs/api-server. When running both the frontend and backend server with yarn cedar serve, and executing a GraphQL resolver that requires auth the api side would crash because the global context was empty.

Running just the api side with yarn cedar serve api, or by using node to run the server binary directly, was not affected by this bug.

Docs

With this release many of the docs versions have been combined. All version 0 docs are combined as v0.x, all Cedar version 1 docs are combined as v1.x and the older Redwood docs are combined as "Redwood v8.x"

🛠️ Fixes

fix(cli): Use cedar instead of redwood and rw (#581) by @Tobbe

Use yarn cedar consistently instead of yarn redwood or yarn rw.

Eventually I want to deprecate rw and redwood. But first I have to start using cedar everywhere

fix(api-server): Explicit CJS export, and named fastify import (#578) by @Tobbe

We build the CLI as ESM only. So, for CJS projects we need to explicitly import CJS versions of other modules to switch over into the CJS module graph.

With the previous implementation we would import the ESM version of @cedarjs/api-server, which in turn would load the ESM version of @cedarjs/context.
When the Cedar app itself loaded something from the api side it'd load the CJS version of the modules, and would so also load the CJS version of @cedarjs/context. With two versions of context loaded auth breaks, because currentUser (and other things stored in context) won't be available everywhere.

In addition to the context ESM/CJS issue there was also a "double wrapped" default export issue with Fastify in @cedarjs/api-server

Fixes #577

fix(deps): update dependency typescript to v5.9.3 (#586) by @renovate-bot

This PR contains the following updates:

Package Change Age Confidence
typescript (source) 5.9.2 -> 5.9.3 age confidence

Release Notes

microsoft/TypeScript (typescript)

v5.9.3: TypeScript 5.9.3

Compare Source

Note: this tag was recreated to point at the correct commit. The npm package contained the correct content.

For release notes, check out the release announcement

Downloads are available on:

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

📚 Docs

docs(branding): Cedarization (#587) by @Tobbe

Trying to find all mentions of Redwood and replacing them with Cedar

docs(docusaurus): Give the 8.x docs a Redwood label (#580) by @Tobbe image

At the end of the list you can see that the old Redwood docs I copied over just to safekeep them are now explicitly labeled "Redwood"

docs(branding): More Cedar, less RW (#583) by @Tobbe

Switch more of the docs over to mentioning Cedar

📦 Dependencies

Click to see all dependency updates

🧹 Chore

Click to see all chore contributions
  • chore(ci): Allow 8 concurrent renovate PRs (c22747a) by @Tobbe
  • Version docs to 2.0 (592a529) by @Tobbe
  • chore(docs): Enable Docusaurus Faster (#575) by @Tobbe
  • chore(internal): Fix structure import for proper types (#595) by @Tobbe
  • chore(docs): Combine all 0.x, 1.x and RW 8.x docs (#579) by @Tobbe

Contributors

Tobbe and renovate-bot
Loading

v2.0.1

30 Nov 15:30
@Tobbe Tobbe
v2.0.1
3e0a750

Choose a tag to compare

View all tags
v2.0.1

This release has no changes compared to v2.0.0

Loading

v1.1.1

30 Nov 21:52
@Tobbe Tobbe
v1.1.1
1147147

Choose a tag to compare

View all tags
v1.1.1

Backporting the following fix to the v1 release track

fix(api-server): Explicit CJS export, and named fastify import (#578) by @Tobbe

We build the CLI as ESM only. So, for CJS projects we need to explicitly import CJS versions of other modules to switch over into the CJS module graph.

With the previous implementation we would import the ESM version of @cedarjs/api-server, which in turn would load the ESM version of @cedarjs/context.
When the Cedar app itself loaded something from the api side it'd load the CJS version of the modules, and would so also load the CJS version of @cedarjs/context. With two versions of context loaded auth breaks, because currentUser (and other things stored in context) won't be available everywhere.

In addition to the context ESM/CJS issue there was also a "double wrapped" default export issue with Fastify in @cedarjs/api-server

Fixes #577

Contributors

Tobbe
Loading

v2.0.0

28 Nov 09:08
@Tobbe Tobbe
v2.0.0
c94d153

Choose a tag to compare

View all tags
v2.0.0

Version 2 of Cedar is here!

This is the first version that introduces major breaking changes. The one change that likely will have the biggest impact on your project is the upgrade to Prisma v6 and Prisma's new config file.

Upgrade guide

Prisma v6 upgrade guide for Cedar apps

  1. Remove the "prisma" config from your root package.json file

       },
-  "prisma": {
-    "seed": "yarn rw exec seed"
-  },
   "packageManager": "yarn@4.9.4",

  2. Create api/prisma.config.cjs with the following contents

    const { defineConfig } = require('prisma/config')

module.exports = defineConfig({
  schema: 'db/schema.prisma',
  migrations: {
    path: 'db/migrations',
    seed: 'yarn cedar exec seed',
  },
})

Generic Prisma v6 upgrade guide

https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-6

Node 24

You will also have to update your deployment environment to use Node 24, because that's now the only supported version of Node.

Please start by reading the release notes for

For Cedar I mainly noticed two changes when upgrading to Node 24:

  1. Node 24 handles dynamic imports a little bit different compared to Node 20 because of Node's continued work to better support projects upgrading from CJS to ESM, and overall moving towards ESM as being the preferred way of writing apps and modules.
  2. I wasn't allowed passing an args array to exec anymore. It became runtime deprecation DEP0190, which caused noisy output to the terminal and some test failures we have for terminal output.

For your own Cedar app you should update the "enginges" field in your root package.json

   },
   "engines": {
-    "node": "=20.x"
+    "node": "=24.x"
   },
   "packageManager": "yarn@4.9.4",

And, like I noted above, you also need to make sure your production environment runs Node 24. How you do that is highly specific to your specific deployment provider, so no further guidance is provided here.

Storybook v8

No matter if you use Storybook or not, I recommend you remove the "resolutions" config in your root package.json

   },
-  "packageManager": "yarn@4.9.4",
-  "resolutions": {
-    "@storybook/react-dom-shim@npm:7.6.20": "https://verdaccio.tobbe.dev/@storybook/react-dom-shim/-/react-dom-shim-8.0.8.tgz"
-  }
+  "packageManager": "yarn@4.9.4"
 }

If you do use Storybook, you'll also want to read their migration notes for v8, https://storybook.js.org/docs/8/migration-guide

Other

Other breaking changes mostly depend on what features of the framework you use as they're specific to what auth provider you use, how you deploy your Cedar app, etc. Please go through the full list of changes below and read more about the changes that affect your app.

Changelog

🚀 Features

feat(baremetal)!: Throw an error if there is not enough available space (49e3dce) by @Tobbe This PR was carried over from Redwood. See the original PR here:

redwoodjs/graphql#11638

Original PR description:

Takes what used to only be a warning (introduced in redwoodjs/graphql#11469) and makes it an error.

The idea/plan here is that existing projects have enough time to first configure their baremetal deployments with a free disk space limit they're comfortable with when they upgrade to the v8 minor that includes redwoodjs/graphql#11469. And then when this PR is included in the next major release of RW they don't need to make any further changes, only thing different will be that they get an error when their servers eventually (if ever) run low on disk space. Just like it will work for any new projects that deploy to baremetal.

So, kind of like first getting a deprecation warning, and then finally having to make the switch. Only here we go from first only getting a free disk space warning, and then later having the deploy fail (with a clear and helpful error message)

feat(cli): Prompt to confirm upgrade (9ae6015) by @pantheredeye This PR was carried over from Redwood. See the original PR here:

redwoodjs/graphql#11601

Breaking

This PR is breaking, because you now have to confirm upgrading. So if you were using yarn rw upgrade in some automated workflow that might now break. Pass in the new --yes flag to skip the upgrade confirmation prompt added by this PR

feat(dbAuth)!: rename cookieName() -> generateCookieName() (70bc683) by @Tobbe This PR was carried over from Redwood. See the original PR here:

redwoodjs/graphql#11771

Original PR description:

Having both the variable named cookieName and the function named cookieName when they're supposed to be used together was very unergonomic

Unfortunately the cookieName() function was exported, so it is possible that someone was using it in their project. And if so, they'd need to update their code to use the new generateCookieName() name.

feat(deps): Upgrade to Clerk Core v2 and Clerk React v5 (#99) by @Tobbe

This PR updates redwood's usage of Clerk authentication to Clerk Core 2 which was introduced back in April 2024 as the new major version for Clerk.

Notable breaking changes:

  • The frontendApi prop is no longer supported on <ClerkProvider>
  • The process.env.CLERK_FRONTEND_API_URL and process.env.CLERK_FRONTEND_API env vars are no longer used (Only process.env.CLERK_PUBLISHABLE_KEY is used)
  • The process.env.CLERK_API_KEY env var is no longer used on the api side.

See https://clerk.com/docs/upgrade-guides/core-2/overview for more details

feat(clerk): Switch to `@clerk/backend` SDK (#102) by @Tobbe

The @clerk/clerk-sdk-node package has reached its end of support back in January. This PR updates the Clerk auth provider to use the recommended JS Backend SDK (@clerk/backend).

Breaking changes

  • Removes the deprecated authDecoder function which used the rate-limited API
    and relied on the now unsupported Node SDK.
  • You now have to specify process.env.CLERK_API_URL, it no longer has a
    default fallback
feat(deps): Upgrade to Fastify v5 (#109) by @Tobbe

This PR is a breaking change. It upgrades Fastify from v4 to v5, so if you're
running CedarJS in a serverful environment you should look through your Fastify
specific code.

Note: For v5 Fastify changed how you pass in a custom logger. CedarJS already
had that code somewhat customized, so for this PR we kept the unified logger
option we already had, so there should be no change for you in that regards,
but we will probably break this appart in the future to match what Fastify is
doing

See the Fastify v5 migration docs
for all the details.

feat(deps): Upgrade minimum supported Node version to 24 (#502) by @Tobbe

Node 20 is currently in maintenance mode, and will reach end of life 2026-04-30
Normally Cedar would switch to the next even numbered Node version. Which would be 22 in this case. But Node 24 is already out and is the current LTS version, so I'm jumping straight to that version.

This is a breaking change. Please read the release notes for Node 22 https://nodejs.org/en/blog/announcements/v22-release-announce and Node 24 https://nodejs.org/en/blog/release/v24.0.0

For Cedar I mainly noticed two changes when upgrading to Node 24:

  1. Node 24 handles dynamic imports a little bit different compared to Node 20 because of Node's continued work to better support projects upgrading from CJS to ESM, and overall moving towards ESM as being the preferred way of writing apps and modules.
  2. I wasn't allowed passing an args array to exec anymore. It became runtime deprecation https://nodejs.org/api/deprecations.html#DEP0190 which caused noisy output to the terminal and some test failures we have for terminal output.
feat(deps): Upgrade to Prisma 6.19.0 (#522) by @Tobbe

Upgrade to Prisma 6.19.0 ✅

This PR successfully upgrades Prisma from version 5.20.0 to 6.19.0, implementing all required breaking changes from the Prisma 6 migration guide.

Changes Implemented

✅ Phase 1: Dependency Updates

  • Updated Prisma dependencies from 5.20.0 to 6.19.0
  • Updated yarn.lock with deduplication

✅ Phase 2: Buffer → Uint8Array Migration

  • Updated all Prisma Bytes field usages to use Uint8Array instead of Buffer

✅ Phase 3: Prisma 6 API Compatibility

  • Replaced ALL getSchema with getSchemaWithPath (Prisma 6 breaking change)
    • getSchemaWithPath returns GetSchemaResult with schemas array of [filename, content] tuples
    • getDMMF({ datamodel }) and getConfig({ datamodel }) accept SchemaFileInput type
    • SchemaFileInput = string | Array<[filename, content]> - both formats supported!
    • All usages now pass result.schemas array directly (cleaner, preserves multi-file info)
    • For string operations (like regex matching), concatenate: result.schemas.map(([, content]) => content).join('\n')
    • Fixed datamodelPath →...
Read more

Contributors

Tobbe, renovate-bot, and 2 other contributors
Loading