[RFC] Presets #634
Description
Current Behavior
Right now, TSDX merges in any external configs with its own, i.e. users with babelrc, eslintrc, jest.config.js, etc don't have full agency over their configs if they want to opt-out of something.
The most confusion this has caused is with tsdx lint, e.g. #514, #498 . Linting tends to very project-specific, and when the rules don't line up 1-to-1 with the config (because it's merged), this is very noticeable and the solution is not intuitive.
The merge behavior also causes problems with Editor / IDE integrations, which has particularly impacted tsdx test as with #270 and its many duplicates and related issues.
This hasn't seemed to have affected tsdx build / .babelrc as much, but can be noticeable in issues like #383, where there have been inconsistencies between babelrc use in commands like build vs. test, as well as #543 where users are unable to change plugin order to that which they need and are stuck with whatever we choose because they can't opt-out easily either (without overriding rollup-plugin-babel in tsdx.config.js).
This merge behavior is not necessarily that uncommon, but some zero-config libraries do use presets instead as well.
Desired Behavior
Allow full overridability of .babelrc, .eslintrc, and jest.config.js when a user wants to do.
Make integrations with existing editor tools more straightforward.
Suggested Solution
Add babel-preset-tsdx, eslint-config-tsdx (or eslint-plugin-tsdx that also has a config for easier installation), and jest-preset-tsdx. Or their equivalent @tsdx/ versions.
Also add a default .babelrc.js, .eslintrc.js, and jest.config.js to all the templates that just use these presets and nothing else to make for instant editor integration.
The ONE issue with this is that the internal Babel config merge is a bit more complicated than a plain merge; it does some custom configuration of preset-env and a few plugins are dynamic based on the options passed to tsdx build. So we'll have to leave some of that custom merging behavior in and may need to account for the case of e.g. babel-preset-tsdx instead of babel-preset-env. Some things can be configured by just allowing users to pass options into the preset, but those won't be dynamic or reflect tsdx build.
Still need to think more on that specific case, will probably be more clear once the implementation is underway.
Could also add a tsconfig.json preset as well, which would make things like #504 not quite as breaking, but might not be so wanted as these get configured more frequently.
Who does this impact? Who is this for?
Any users with custom Babel, ESLint, or Jest configs.
Any users of the default editor integrations with those.
NOT users who don't configure and NOT users who don't use those editor integrations.
Describe alternatives you've considered
There isn't another way to give full agency to users and that's kind of the problem. Well tsdx build can be mostly overridden with tsdx.config.js, but tsdx lint and tsdx test cannot.
This is the reason that this change would be a fairly BREAKING change, as people who used those configs with merging would suddenly stop getting merged and would have to switch to using the preset instead.
Editor integrations can be customized, but we want a more zero-config out-of-the-box experience for editor integrations too.
Additional context
Something I've been considering for a while as it's popped up in a lot of places for different parts of the codebase. Have linked a number of issues above.
Some other past references to having presets:
#110 (comment)
#389 (comment)
There is also precedent from kyt, which uses presets now and is a package Jared imitated when creating TSDX per #289
Per #634 (comment), Parcel 2 seems to do this for its Babel support as well