Repository navigation
Allow opting out of multi-logger TUI #4432
Description
Pre-flight checklist
- I have read the contribution documentation for this project.
- I agree to follow the code of conduct that this project uses.
- I have searched the issue tracker for a feature request that matches the one I want to file, without success.
Problem description
I would prefer Forge not to be a terminal multiplexer, for a few reasons:
- It strips colors from the app's terminal output
- I already have a terminal with its own mechanisms for scrollback, finding text in the backlog, etc., which I'd rather use
- I'm not using Webpack, so the tab functionality currently isn't helpful, and the multiplexer covers the Vite plugin's console output
The current options for disabling the multiplexer (setting CI or piping output to a non-TTY) have significant downsides compared to the status quo in Forge 7:
- They require extra boilerplate on the command line
- Colors are still stripped
- Every log line has
[App]prepended to it - I don't want other code to think it's running in CI or in a non-terminal environment
Proposed solution
I'm not sure what the most graceful approach would be here. I guess it might be three distinct changes: one to add a new LoggerMode called flat or something, one to allow configuring the logger mode in forge.config.ts, and one to stop prepending [App] if we're in a non-ink mode and only one tab is registered.
Alternatives considered
There are some things here that could be improved within the current TUI—like the Vite plugin could use the shared logger so it doesn't get covered up, and the color issue is probably fixable—but I fundamentally just don't want Forge to own my scrollback.
Additional information
No response
Activity
rf- commentedon Oct 3, 2026
I looked into this a bit. I think adding a new logger mode may actually be unnecessary—I’d been assuming we’d need different color handling between
flatandplainmodes, but it seems like we’re actually ok with printing ANSI codes inplainmode, and I think this is consistent with the non-tty behavior in Forge 7.That suggests we’d just need:
forge.config.ts, which calls the existinglogger.forcePlain()method once the Forge config is resolved. This is still necessary because settingCIand piping stdout are awkward and have other side effects that are undesirable in dev.[App]unnecessarily.I’m not sure if there are any other subtleties I’m missing here.
rf- commentedon Oct 4, 2026
Oh, I see now that the issue isn't that colors are being stripped, it's that
process.stdout.isTTYis false in the subprocess, which wasn't true in Forge 7 because it usedstdio: 'inherit'.In Forge 8, we use
inheritonly when Forge's overallinteractiveflag is false, which is only true when stdin isn't a TTY. So, weirdly, the color and[App]issues can be fixed by running the app withecho | npm run start, although this causes other side effects and prevents using therscommand.I'm not really sure what behavior we want here. Personally, my preference would be for spawned processes to inherit stdio iff
logger.mode === 'plain', and then PlainRenderer can just print the tags for the extra log streams coming from the Webpack plugin.feat(core): Expose logger's `interactive` option in Forge config
feat(core): Expose logger's `interactive` option in Forge config
feat(core): Expose logger's `interactive` option in Forge config
feat(core): Expose logger's `interactive` option in Forge config (#4434)