I just launched a React Component library from start => finish last week using TSDX and typescript 4.2.3. I was similarly concerned about the update cycle but have been trying to get over the mental hurdle that few updates = bad project. Few updates could simply mean that the baseline functionality is good enough and that was exactly the case for me and my team last week.
Obviously, YMMV but just wanted to give a +1 to a tool that made my life a little bit easier recently!
I'm a pretty unhappy user of tsdx. While it kind of gets the job done, they've broken my project several times with upgrades. As also noted, the project has stalled. If I was doing another project, I'd avoid it if possible.
If you are intending to make a relatively isolated library, in its own repo, that you publish to npm, tsdx might be a good starting point.
In my case, that was not my requirement, and I started with tsdx and regretted it. It's way too much for an early project -- you should really add these things as you find out that you need them. In my case the main issue was I was using it in a monorepo and having duplicated tooling and watch scripts in each library was not great for memory usage nor build times nor hot reload times. (In fact, even by itself, tsdx had some really bad build times compared to compiling the code as part of a Next.js build).
In terms of monorepo, FWIW I'm now using .tsconfig project references [0], Yarn Berry workspaces, next.js externalDir experimental flag, judicious usage of `extends:`, and a shared package with common development scripts. I'm fairly happy with the setup now, but it was a huge PITA to get there, and a lot of the features only became available in the last year. But I'm relieved to be relying on officially supported TypeScript features, operating under the assumption that the TS team is incentivized to keep improving build times for this use case (which, in fact, they use in their own repo).
I've also been eyeing Rush [1] for monorepo management but haven't pulled the trigger yet. I think they are making all the right decisions. The real challenge with a monorepo, and one I haven't fully solved yet, is balancing the tradeoffs of "passive compilation" (importing from the source of sibling packages) vs. bundling each package separately. As a small team, passive compilation is somewhat okay, and tsconfig project references kind of enforce boundaries, but on a larger team it could become problematic. On the other hand, bundling each package separately is not a great dev experience when each bundler is eating 1gb of RAM and running its own hot reload process.
I just tried out tsdx. The node_modules folder took ~180MB of space in a fresh project. I don't know if I am doing or judging things wrong, but this seems to be way too much if someone just wants to write some hobby project exploratory code.
I am probably not the target demographic for tsdx or other bootstrap libraries in the ecosystem but I would love to have something "simple" with good defaults which I can debug if something breaks to make CLI scripts to familiarise myself with the language and ecosystem.
Currently the best option for me is to manually setup the directory structure and build commands which is not fun for mostly simple throwaway code.
golang and rust seem to have things right in this regard though rust build artifacts can get quite big.
* It hasn't been updated for six months
* It doesn't appear to support TypeScript 4 properly[1]
[1] https://github.com/formium/tsdx/issues/926