search

jaredpalmer / tsdx

Zero-config CLI for TypeScript package development
https://tsdx.io
MIT License
11.26k stars 508 forks source link

Run `npm start` command for the project and the "example" app at the same time #735

Closed gavinr closed 4 years ago

gavinr commented 4 years ago

Current Behavior

To get started developing, I run npm start in the main project folder, open a separate terminal, browse to the example subfolder, and run npm start there. This is cumbersome.

Desired Behavior

A single command that kicks off both of the npm start commands above.

Suggested Solution

Some sort of script that runs both at the same time without causing timing issues (see Describe alternatives you've considered below)

Who does this impact? Who is this for?

Developers using TSDX

Describe alternatives you've considered

I have attempted to use concurrently but that causes race condition errors as sometimes one script starts before the other and vice-versa.

Additional context

Thank you for tsdx, and for the support.

agilgur5 commented 4 years ago

I understand that it may feel cumbersome to you, but this is a workflow used by many. Some folks even have a third terminal for tsc --noEmit. The outputs are quite different in each of those streams, so interleaving them may actually cause quite a bit of confusion. I would prefer to stay the safer and less confusing route, but if you'd like to interleave them, you are free to do so in user-land using something like concurrently or even the simpler Unix & to run a command in the background.

Furthermore, the example is only part of the TSDX template and not actually controlled by TSDX itself. Whether you even use an example dir, use Parcel, have a similar command, etc is not something TSDX has control over (at least not right now; perhaps in the future it may be more opinionated). That being said, we could add another script only to the template.

There are already some quite confusing behaviors in TSDX that have caused users a lot of headaches and that are taking some breaking changes to fix. Adding a new, confusing option requires feature work and then a new maintenance burden for a new API (and the burden is quite a lot higher for confusing features). For a feature like this, interleaving a tsc --noEmit stream, a tsdx lint --watch stream, a tsdx test --watch stream, etc, are things I could see be made as feature requests on top of that too; it becomes difficult to draw a line there, so it's not quite as simple as just adding something.