Run develop/watch from workspaces #350
-
Hi, thank you for this awesome starter. I wonder what you would recommend for watching/developing all packages at the workspaces level? concurrently? preconstruct? Of course we can run commands separately at the package level, eg. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
Hey @ekafyi About preconstruct
Nice links, but actually we don't need any build to use / develop in packages. A change in any package will immediately be reflected in your apps (fast-refresh)... And yes it wasn't that easy before and things like preconstruct made a sense. If you're wondering how this magic happens, all is the readme. The key points are: In an app:
You'll see basically point 1 & 2 are a safe way to really ensure your boundaries (deps are explicitely set and mirror each others. I say that because with typescript path aliases you can access pretty much any kind of files)... Same strategy that NX will inject for you for example. Point 3 is a new mechanism offered by nextjs, that allows to consider typescript aliases paths without any additional config. If you're on an older NextJs Version, see the readme. In other words, nextjs app will just use your packages files just like they were belonging to the app and only use what's needed... Last but not least, all caches, typechecks, fast refresh will give you a very good developer experience. (rather than watching, pre building...)
I just start with the app I'm working on When my work implies a change in a shared package (ie consumed by multiple apps) there's a possibility that my changes would break another app. eg: I change a component prop (a boolean, by a string). This possibility is most of the time catched by typescript (or unit-test or builds in the ci), it increases a lot my confidence to not creating breaking changes across the apps. (or to see it earlier where I can eventually act on them, choose a different path...). There's more to say, but it's a bit how I work for a year or two. A lot less mental overhead 😄 I don't really know if it's best practice though. About concurrently
As seen above, I don't need to watch concurrently. But sometimes I need to run commands concurrently. As you'll see in the ie: It's a nice to have and completely integrated experience. See the root package.json to see how I use it. In older versions of monorepo I was using, I tend to use lerna for this (as a taskrunner)... And sometimes I use One thing I'd like to add in this example is ultra-runner at some point, it gives a little extra boost. Nice gem... I'm not sure if it answer your question, but hope it helps. |
Beta Was this translation helpful? Give feedback.
Hey @ekafyi
About preconstruct
Nice links, but actually we don't need any build to use / develop in packages. A change in any package will immediately be reflected in your apps (fast-refresh)...
And yes it wasn't that easy before and things like preconstruct made a sense.
If you're wondering how this magic happens, all is the readme. The key points are:
In an app:
package.json
define your internal package dependencies (prefer using workspace: protocol). more detailspackage.json