feat: CLI event hook flags #4457
Conversation
There was a problem hiding this comment.
Actually I think this is an interesting idea with minimal impact. If you add tests and documentation, I would merge this. execSync sounds fine to me as I think this would help the expectation that the command can be executed at exactly the point in time where the event happens, and we also do not expect unrelated tasks to share the event loop.
Codecov Report
@@ Coverage Diff @@
## master #4457 +/- ##
==========================================
- Coverage 98.75% 98.72% -0.04%
==========================================
Files 205 206 +1
Lines 7331 7351 +20
Branches 2082 2086 +4
==========================================
+ Hits 7240 7257 +17
- Misses 33 34 +1
- Partials 58 60 +2
Continue to review full report at Codecov.
|
|
lukastaegert Cool cool. I'm going to try and carve out some time next weekend or the weekend after to follow up on this MR and add tests and documentation. I'll ping you when that work is done for you to re-review. Thank you! |
| bundles main.js → _actual... | ||
| watch.onBundleStart $ echo bundleStart | ||
| bundleStart | ||
| created _actual in 16ms |
There was a problem hiding this comment.
A CLI test must not depend on things like runtime. The usual solution is to use assertIncludes for substrings like created _actual etc.
There was a problem hiding this comment.
Another idea: Split the output by line, filtering empty ones and mapping the remaining ones to their first word. Then you would just need to compare
start
bundles
bundleStart
created
...
| module.exports = { | ||
| description: 'onStart event hoot shell command executes correctly', | ||
| command: | ||
| 'rollup -cw --watch --watch.onStart "echo start" --watch.onBundleStart "echo bundleStart" --watch.onBundleEnd "echo bundleEnd" --watch.onEnd "echo onEnd" --watch.onError "echo onError"', |
There was a problem hiding this comment.
lol oops.
I could use some guidance on how to do this test exactly. The test/cli/samples/ suite of test all seem to do tests on either console output or bundle file output. the one I threw up there was just a POC to test all of the watch event hooks at once by just looking for the echos being written
I can get that test working or I can take another direction. Would you like me to break up each hook into its own test? should I test that --silent doesn't print to stderr?
There was a problem hiding this comment.
No, I think the test is fine in principle, and testing all hooks together seems adequate to me considering me that there is not too much logic involved. You should just make sure to make it a little more robust, e.g. see my other suggestion of preprocessing the output by splitting it into lines, doing some mapping and filtering and possibly doing an deepStrictEqual on the result. Looks to me like "echo" should also work on Windows, which is definitely a bonus.
|
I have 2 passing tests (had to test I added in this that I found in a similar test file, though it doesn't help: abortOnStderr(data) {
if (data.includes('waiting for changes')) {
return true;
}
}What am I doing wrong? |
|
Looks like a process is not terminating correctly and needs to be force-quit by the test framework after the 40s timeout |
|
I figured out the missing piece for the testing not exiting on |
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
Description
Overview
When in watch mode, it is not uncommon to want to kick off other tasks at the start or end of a bundle. The built-in CLI already has callbacks set up for the 5 events. This MR sets up config and cli flags to be able to set up custom hooks to run on those events in addition to the current operations.
This MR is incomplete on purpose. Before writing tests and updating documentation, I wanted to see if this feature is something the core team would like. See below for list of TODOs
Motivation
I work I use
yalcheavily when developing locally. We userollupas well. Right now are running a separaterollup -c --watchandchokidar dist -c 'yalc push'to marry incremental builds fromrollupand moving the results of that build to other libs viayalc.The
chokidarwatch is not necessary though becauserolluphas event hooks for'START','END', etc. Except the built-in CLI currently only uses those hooks to display build information. It would be great to runyalc push, or any terminal command for that matter, at any of these hook points via the built-in CLICurrent Implementation
Using the systems already in place, I added the following CLI flag:
Each value is passed to
child_process.execSync. To be run.stdiois set toinheritunless--silentis set, then it isignore. I choose to useexecSync, but I'm not opposed to usingexecorspawneither, whatever the rollup team would like, just let me know what would be preferred here.I specifically choose for these to be CLI options only since the intention is to add terminal commands to the built-in CLI. These would never apply to
WatchOptionspassed in API, egconst watcher = rollup.watch(watchOptions);, as users writing scripts utilizing the API would implement their ownwatch.on('event')to do what they neededTODO
As mentioned before, I wanted to gauge if the rollup team would be open to accepting this MR before I completed it
Final Thoughts
Thank you for the consideration of this MR. IMHO this feature is the main thing missing from the CLI. The level of effort it too to add this feature was minimal, yet it adds a lot of power to users.