Improve internal configs generation
See original GitHub issueCurrent 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
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Store configuration data using Docker Configs
How to store configuration data separate from the runtime. ... configs for a container are all mounted in C:\ProgramData\Docker\internal\configs (an ...
Read more >Configuration Best Practices
This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started ...
Read more >Create and edit configurations - Visual Studio (Windows)
Open the Configuration Manager dialog box. Select a project in the Project column.
Read more >How to Write a Configuration file in Python | by Xiaoxu Gao
Option5: Hydra- Simplify the development by dynamically creating a hierarchical configuration. The last option is much more than just a file ...
Read more >Customize pipeline configuration - GitLab Docs
You can customize how pipelines run for your project. For an overview of pipelines, watch the video GitLab CI Pipeline, Artifacts, and Environments....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.
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:
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!