Tsdx: Improve internal configs generation

[ambroseus]

Current Behavior

As mentioned in README: _TSDX is a zero-config CLI that helps you develop, test, and publish modern TypeScript packages with ease_

but there are a lot of issues that need to fix / patch / extend configs for ts / babel / jest / rollup / rollup plugins / plugins for rollup plugins etc. see https://github.com/jaredpalmer/tsdx/issues/379

Desired Behavior

ability to easy deal with all kind of configs

Suggested Solution

need to discuss

EDIT: per below suggestions: use patch-package

Describe alternatives you've considered

possible simplest solution (as CRA): tsdx eject

---

Maintainer/agilgur5 edit: lightly reverted some edits for posterity because this was one of the first places tsdx eject was mentioned and rejected. I got confused myself when I re-read this after it was edited out too

[sw-yx]

i'm open to this idea (i prefer shadowing rather than ejecting) but also the user can modify the rollup config via tsdx.config.js. What do you think is the tipping point between modifying via config and total ejection?

[ambroseus]

@sw-yx I also prefer to deal with merge approach instead of full ejecting configs but..
periodically during issue investigation I want to see full configs to understand what is passing to exact tool (tsc, babel, jest, rollup, rpt2 etc.)

it will be good to extend tsdx.config.js to deal with other configs

[sw-yx]

alright. im not as strongly opinionated on seeing full configs but this is really something Jared will have to decide.

[jaredpalmer]

So ejection is not gonna happen. My goal with TSDX is to eviscerate boilerplate from typescript by providing a single abstraction with solid defaults that’s infinitely customizable.

To make this strategy a reality, we always need to ensure that that the correct escape hatches exist. That is mission critical to the project’s continued success. I believe we should address each specific use case and decide to adapt or document a solution.

Lastly, and maybe we should also document this, I have found that patch-package is a wayyyyy better approach to modifying create-react-app instead of ejecting. Most of the time I only need to tweak 10-15 lines of webpack, and am not interested in foregoing the rest of the updates. If tsdx.config.js isn’t sufficient, patch-package is my suggested final escape hatch.

As for understanding the various configs, I agree it could perhaps be restructured internally to use deep merge instead of just functions. However, I’m not 100% sure if it’s going to make that big of difference. Since we are outputting up to 3 formats for n entries, we are going to have functions regardless. We could technically augment tsdx config to have a deep merge mode like storybook does. Personally, I don’t care for this, because I like being able to log everything. It also gets weird with dev/prod and different formats....something that storybook doesn’t need to think about.

So in conclusion, no to an eject command. Yes, to documenting patch-package as ultimate escape hatch and yes to fixing or documenting each issue and solution.

[ambroseus]

@jaredpalmer so.. let say NO for ejecting :) and many many tanks for the patch-package approach!

[agilgur5]

Since I've changed a bunch of the internal build logic in #367 and would like to refactor some internals once it's merged, I do think there are some other ways to make pieces of TSDX easier to extend:

1. Splitting things up into a babel-preset, eslint shareable config, etc. Would be easier to understand each in isolation and better than having lots of build scripts added to your repo from ejecting
   
   
   
   1. More specifically, creating a rollup plugin(s). I need to read through how the rollup plugin API works (TSDX was my first usage of Rollup), but I believe it should be possible to convert a good portion of the build config into a rollup plugin (probably wrapping rpts2) or several rollup plugins. Not sure if this was something you tried & decided against in the past @jaredpalmer
   
   
2. More "accessible" customizability similar to customize-cra

"Stuff can break" is also a noteworthy factor around tsdx.config.js. Those changes can be quite fragile -- they effectively target the private, internal API of TSDX (not the public one), meaning there's little semver guarantee there and lots of room for breakage like, for instance #386 . Using a different TS plugin, for instance, would clobber some of those customizations, even if the public APi were unchanged.

I'll PR a disclaimer/warning for that in the docs, but that's another reason why I think splitting pieces of TSDX into plugins would be useful -- together they make up the private, internal API, but individually each exposes its own public API. Breaking changes in plugins would not necessarily translate to breaking changes in TSDX

---

Also, for posterity's sake, #110 and #183, that introduced tsdx.config.js a few months ago, are of course very related discussions to this. Presets are mentioned there too!

[ambroseus]

@agilgur5 +1 for tsdx plugins approach :)