egoist / egoist/tsup

[ request ] allow an option for multiple configurations to be run in sequence instead of parallel

Open
#577 1 comment 2 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
11.3k
Forks
275
PR merge metrics
No merged PRs in 30d

Description

First, thank you for this library. It has been hugely helpful for several of my projects.

I took advantage of the feature in `tsup.config.ts` that allows multiple configurations to be passed in, which then run in parallel.

**edit - accidental submit **

anyway. I've hit a couple situations now in which it'd be good to be able to be able to do one of two things:

* run these configurations from different config files, with a CLI option to choose which config is used, or
* offer an option to run JS/TS-based configs in sequence, for situation in which one script depends on another having been run

One use case ( that inspired the request ) is the building of an icon pack that will be consumed by TS projects.

I have a folder of raw SVGs. At first, I tried to use the SVG and SVGR plugins for esbuild, which worked.

But then issues arose with DTS generation. tsup puts out .js files in both cases, and the step was failing because the `index.d.ts` file was putting out paths to the pre-build SVGs rather than the .js files they became.

I found that I could get everything working by doing some shell scripting to replace the file extensions in the `index.js` file to change to `.js` from `.svg`, then running tsup again on that modified / already bundled once folder to get it into a format that the `--dts` option could handle.

But this required a second tsup config, and that one went into a bash script instead of being with the others in the `.ts` config.

I know this particular situation is niche. but it would have been a cleaner and more consistent result for the config to be able to run some scripts in the `onSuccess` of the first path, knowing that the second pass for types would know to wait until it was done.

It's the kind of thing that _sounds_ like it wouldn't be a crazy change, and i'd be happy to raise a PR if I could get pointer on where to start. Also would be happy to line out other use cases where this kind of thing would be helpful - such as packages with export maps, with different modules that may require different build options and may depend on others being built first.

Hope this issue request finds you well, let me know if I can be of any assistance in making it happen!

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.