Guide on Redwood Package Development!

A section in

That goes though how to create packages for redwood specifically. Like for example redwood-auth, what it takes to build both api side as well the frontend and maybe how to create generators.

1 Like

This is a great idea :+1: Not sure if our team has the bandwidth quite yet to do this now, but it’s definitely on our radar.

For now if anyone is looking to dig into package development and how we handle things, you could start by with this doc (below) and attempt to get your local dev setup working.

Has anyone else already tried this and experienced success or challenges? If so, care to share your stories?

1 Like

I think yarn build needs to be emphasized more. Particularly after cloning redwoodjs/redwood and running yarn install. Right now, doesn’t explicitly say to do this:

Assuming you’ve already cloned redwoodjs/redwood locally and run yarn install , navigate to the packages/cli directory and run the following command: yarn link

When trying to run chmod +x node_modules/.bin/redwood && yarn redwood generate page home / (I didn’t generate scaffold MyModel as written in–I assumed it would fail since I didn’t have a table named MyModel) in my testing app, I kept getting this error:

Cannot find module '/home/dominic/projects/redwood/redwood/node_modules/@redwoodjs/internal/dist/main.js'. Please verify that the package.json has a valid "main" entry

After actually reading the error message, I realized main.js didn’t exist because I didn’t run yarn build inside redwood/internal. The only thing I built out was packages/cli.

Amending that aforementioned paragraph in would prevent this from being an issue:

Assuming you’ve already cloned redwoodjs/redwood locally and run yarn install and yarn build, navigate to the packages/cli directory and run the following command: yarn link


100%, could you open a PR and mention that?

1 Like

Absolutely, just did:

Speaking of yarn build. I was wondering if it’s possible to yarn link dependencies to the src of the package. Then including these packages in the webpack babel-loader. This way there’s no need for yarn build + your local project linking to the redwood package would hot-reload on changes in the package!

I’m not sure if it’s easy to do this. I’ve tried doing this with @redwoodjs/web and it Almost Works™

We’re doing a similar thing at the company I’m working at. Except we don’t use yarn link, but we just alias @com/package to ../local-package in our

@peterp @thedavid You think this is something worth looking into?

1 Like

@Robert worth thinking about == yes, please!! This is something that comes up at least once a day. The local dev workflow between packages and the App is just, well, painful. I just got done with some work on my Windows virtual machine and about threw my physical machine out the window :computer::boom:

Our thinking has been a bit different, but the webpack approach is really intriguing. Some early thinking was scribbled down in Issue #109 And @peterp recently started (then stopped) some work on this PR:


Wow @Robert You’ve just given me an idea for doing this with babel.config.js!


@peterp Curious to see what idea I gave you :nerd_face:

If this is not a priority for the core team at the moment I’d be happy to give it a shot if you think it’s something I can pick up :+1:

EDIT: I couldn’t stop myself from playing around with this and I got it to work with this commit:

This allows you to run yarn rw dev in your project that has core and router symlinked and your project will hot-reload on editing files in the router package.

I know this probably breaks a couple of things when releasing, but I thought I’d share it in case it’s helpful!