Road to stable

[SimplyLinn]

So, there's a fundamental issue with how this project is developed right now:

It's not "lockfile friendly", this was intentional in the beginning, lockfiles locked us to a specific commit, and with the rapid iteration and plentiful updates, it was unfeasible to try and keep a sane lockfile due to the increase in iteration time for every change.

At which point do we consider things mature/stable enough that we should keep development of the root next-dashboard project and the application projects separate? It needs to happen at some point, because this setup can NOT go live, it should barely be a thing on staging.

Decoupling development would mean a rather big shift in how development would happen and we would have to have another discussion about how to efficiently add more features to this project when needed, but I'm starting to feel the drawbacks of the "rapid development compromise" is starting to outweigh the benefits it had in the beginning.

Thoughts? Should we have a meeting about this?

[FireyFly]

Hmm. Why is it a problem to track next-dashboard to a specific commit rather than HEAD?

I'm envisioning something like the downstream consumer projects depending on github.com/PiJaAB/next-dashboard#. Keeping a lockfile would still make sense as far as I understand it. I think you could still update both projects in tandem much like we have been doing, except each time next-dashboard is updated, we'd have to update which specific commit a consumer project is depending on. Effectively this would be using specifically the next-dashboard dependency in a lockfile-y kinda manner. I figure the bumping could be automated or at least partially automated.

A benefit here would be that it would be less imperative (but probably still desirable) to make sure all projects work with HEAD at all times, since a project that lags behind a bit could happily still point to an older commit and still function.

I might be missing a reason for why this doesn't work at all (and this might've been something we tried when setting things up?), so please do correct me if I'm wrong :D

[SimplyLinn]

Well, the issue was this:
Yarn workspaces does not properly link the projects with yarn magic, so in order to get a proper lock file, every PR to dashboard project you'd have to do this:

• do yarn cache clean to get rid of the cached github URL from yarn (you could add a parameter to just clean the next-dashboard cache and thus not nuke the entire cache)
• do yarn install <github url> to install the project and update the lock-file inside the project folder itself
• push to git to update the branch/PR lockfile
• do yarn magic in the root project again to return to "development state"

This added several layers of confusion when people were already having a hard time grasping the worflow of yarn workspaces in general, not to mention I was still learning and had a hard time explaining something I was just beginning to grasp myself. We're further into the future now, and adding this to the workflow may be feasible, but it was not before people actually got used to workspaces.