I burned few months evaluating and trying out different options, trying different structures of cross platform project, all typescript in Nx and eventually went with it. The main thing which convinced me was having single package json.

Besides, yes, nx comes with a single configuration file for each project, but alongside of it are jest, eslint, babel and app/lib/spec/ide tsconfig configs - that’s a lot! All of this shouldn’t be visible to the developer. Initially, when trying to find myself in this mess, I thought that the solution lies in autogenerated ide workspaces - for vscode and sublime. But in practice it wasn’t that helpful, because there is always something which is not handled by autogenerate multiroot structure but is needed, so one needs to have multiple windows open anyways.

Hopefully typescript 5.0 is going to help reduce some of this boilerplate with multiple tsconfig base classes, so lib/app/spec/ide tsconfigs will be able to extend from common base, which currently is not possible.

The worst part is that those webpack configs are hard to override, however they tried to simplify it a little bit in recent releases. And there is lack of ssr support, so I had to patch nx with patch-package to generate obfuscated css classes in prod, because currently it’s not possible with their webpack executor!

In other words it’s all about dx, and as someone mentioned in previous comments, dx is not primarily improved by lack of config files, but by having semantic structure of the actual code, clearly knowing what depends on what and where one can find it. Right now we are on our own, because there is lack of information on how to structure cross platform codebase properly. I strongly believe it will change though.

If you have any questions and what to know my pains please let me know.

Ps. Nx has a nice blog post why they do t use bazel under the hood https://blog.nrwl.io/on-bazel-support-6be3b3ceba29