What are recommended monorepo tools that work well with dagger? I'll be splitting a nextjs app into an app, library and second app not yet using dagger nor any monorepo tools. I've looked at nx and considering my options. Thanks.
#monorepo tools & dagger
small herald
dawn shoal
Can't make a suggestion on any particular monorepo that works with Dagger per se, but I can suggest a monorepo management tool you probably haven't seen yet called Rush. Have a look. https://rushjs.io/
small herald
Can't make a suggestion on any particular monorepo that works with Dagger per se...
I have heard about it, it was not on my top list. What is your experience with it, and why do you think it should be on the top of my list?
Others please keep the suggestions coming!
dawn shoal
I have heard about it, it was not on my top list. What is your experience with ...
Welp. Rush just made more sense to me from the start. The docs are more logical and were easier to follow at the time (about 2 years ago). I'm looking at the Nx docs now again, and they still look all over the place to me. 🤷🏻♂️ I believe Rush is less complicated than Nx, but Rush is just as feature-rich.
small herald
Welp. Rush just made more sense to me from the start. The docs are more logical ...
You are working with Rush then? You looked at the Nx docs now because of my question or something work related?
Is your experience with nextjs?
dawn shoal
You are working with Rush then? You looked at the Nx docs now because of my que...
I looked at the docs because of your question. I wanted to see if Nx was still so convoluted.
And yes, I work with Rush. I've even built a CLI app that uses Rush's graph algorithm to run watchers on different dependencies, along with running a dev server. So, for instance, imagine running a dev server with a dependent library, and you wish to work on both the library and the code in the server. Well, with a my-cli-command dev project1 project2 I have the library watched and when it recompiles, the dev server restarts too. It's much better than using concurrently, because it accounts for the dependency graph and it is much much better than opening two or more terminals.
The framework is Vue. The meta-framework is Quasar. Next is React. 😉
small herald
Since our apps are for now nextjs and I've found https://github.com/microsoft/rushstack/issues/4477
so I won't be rushing to Rush.
dawn shoal
Nice find. But, it sounds more like a Next problem than a Rush problem. Non-configurable cache and compilation output folders?
This is also a question that is in my mind. If Dagger does build caching too, does the monorepo also need to cache its outputs? 🤔 Because, the build cache in Rush is for CI purposes, which is what Dagger's cache can also be used for.
I also added a comment to that issue with what I believe might be a solution for the Rush cache side of things. It's uncertain to me, if that is a solution for that problem though.
I also asked the caching question more specifically.
small herald
As the owners of NextJS also own Turborepo which competes with Rush, I am skeptical if nextjs would be open to making them configurable.
Interesting question about the Dagger and Rush caches.
Re your suggested solution of nextjs standalone, not being an expert on nextjs, but I believe that is related to the final deployable output verse the nextjs cache used to create that deployable output, if I'm correct (which I might not be), your solution would not help. (We ourselves are actually doing: output: export and deploying the resultant files to our existing host (using nextjs in a client side only mode)
dawn shoal
@small herald - Rush tracks the changes in the project and only rebuilds, if something internal changed. If it didn't, it reuses its cache, which should be a build output folder. So, if the build output folder is separated, then the two caching processes (the dev server cache in Next and Rush's build cache) won't collide, which is what the issue was noting as the problem.... from my understanding. 🙂