Skip to content

Feature/cli status - #1811

Open
jeregon1 wants to merge 8 commits into
hovancik:trunkfrom
jeregon1:feature/cli-status
Open

jeregon1 wants to merge 8 commits into
hovancik:trunkfrom
jeregon1:feature/cli-status

Conversation

@jeregon1

Copy link
Copy Markdown

Issue: #1628

Requirements

  • issue was opened to discuss proposed changes before starting implementation.
  • during development, node version specified in package.json was used (v22+).
  • package versions and package-lock.json were not changed.
  • app version number was not changed.
  • all new code has tests to ensure against regressions.
  • npm run lint reports no offenses.
  • npm run test is error-free (24 new tests pass).
  • README and CHANGELOG were updated accordingly.
  • after PR is approved, all commits in it are squashed.

Description of the Change

Adds a stretchly status CLI command that shows the current break state without opening the GUI. Supports both human-readable text output and --json / -j for machine parsing (integration with polybar, i3status, etc.).

States detected:

  • no_active_break — shows time remaining until the next mini and long break
  • active_break — shows break type (mini/long) and time until it ends
  • paused — shows that breaks are paused
  • Unavailable — when no Stretchly instance is running

Snapshot-based architecture: The running instance periodically writes a JSON snapshot file. Any second instance reads this file to display status, avoiding IPC complexity and keeping the first instance unmodified.

Verification Process

  • npm run lint — clean
  • npm run test — 24 new tests + 32 existing = 56 passed
  • npm run pack — builds successfully on Windows
  • Tested edge cases: paused, active mini break, active long break, no active break, missing planner, missing settings
  • AI-assisted contribution

jeregon1 added 3 commits June 22, 2026 22:56
- Extract pure snapshot logic to app/utils/cliStatus.js
- Add --json/-j option to status command
- Wire --json flag through both instance paths in main.js
- Detect paused state in status output
- Delete snapshot file on app quit
- Add 24 unit tests for all three exported functions
- Update CHANGELOG
…n fields to JSON output

- Replace app.quit() with app.exit(0) in status handlers to
  bypass before-quit handler (globalShortcut not ready)
- Add time_to_*_human and long_break_enabled fields to JSON output
- Rename time_to_* fields to time_to_*_ms for clarity
- Update printJsonSnapshotAsText to use new field names
- Update tests to match new JSON shape
Copilot AI review requested due to automatic review settings June 23, 2026 10:49

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds a stretchly status CLI command intended to expose the current break state without opening the GUI, with optional --json / -j output for status bar/script integration. It implements a snapshot-based approach by having the running instance write a JSON snapshot to the user data directory, which subsequent invocations can read.

Changes:

  • Added CLI parsing/support for a new status command (including --json / -j).
  • Added snapshot generation utilities (app/utils/cliStatus.js) and a new test suite covering status formatting/snapshot building.
  • Updated documentation (README/CHANGELOG) to mention the new CLI behavior.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file
File Description
test/commands.js Adds coverage ensuring --status is recognized and not forwarded to the main instance.
test/cliStatus.js Adds tests for duration formatting and status snapshot construction in text and JSON modes.
README.md Documents the new status CLI usage.
CHANGELOG.md Notes the new CLI status command and JSON flag.
app/utils/commands.js Registers the status command and --json option; adds examples; tweaks parsing for --status.
app/utils/cliStatus.js Introduces snapshot building + long-break time computation helpers.
app/main.js Writes status snapshot periodically (via tray update path) and adds logic to print status from snapshot / headless run.

Comment thread CHANGELOG.md Outdated
Comment on lines 27 to 31
=======
- `stretchly status` command to show current break state from CLI
- `stretchly status --json` flag for machine-readable JSON output
>>>>>>> f254297a (feat: implement stretchly status command with --json flag)
- advanced option for Break Health Mode
Comment thread README.md Outdated
When a Stretchly instance is running, the `stretchly` command can be use to interact with it from the command line.

Type `stretchly help` to get a list of all commands and options available as well as some examples.
Type `stretchly --status` to see either active break details (type + time remaining) or, when no break is active, time to next break and next long break.
Comment thread app/main.js
Comment thread app/main.js
Comment on lines +1402 to 1406
writeCliStatusSnapshot()

if (!appIcon && !settings.get('showTrayIcon')) {
return
}
Comment thread app/main.js Outdated
Comment on lines +380 to +384
const startupCommand = new Command(commandLineArguments, app.getVersion(), false)
if (startupCommand.command === 'status') {
printCliStatusAndQuit(startupCommand.options && startupCommand.options.json)
return
}
Comment thread app/utils/cliStatus.js
Comment on lines +67 to +73
if (json) {
return {
status: 'active_break',
break_type: reference === 'finishMicrobreak' ? 'mini' : 'long',
time_to_break_end_ms: breakPlanner.scheduler.timeLeft,
time_to_break_end_human: formatCliDuration(breakPlanner.scheduler.timeLeft)
}
@codecov

codecov Bot commented Jun 29, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.50000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 71.04%. Comparing base (888f1f1) to head (606cfd7).
⚠️ Report is 26 commits behind head on trunk.

Files with missing lines Patch % Lines
app/utils/commands.js 80.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##            trunk    #1811      +/-   ##
==========================================
+ Coverage   67.39%   71.04%   +3.65%     
==========================================
  Files          16       18       +2     
  Lines         506      563      +57     
==========================================
+ Hits          341      400      +59     
+ Misses        165      163       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@hovancik

hovancik commented Jul 1, 2026

Copy link
Copy Markdown
Owner

Hi and thanks for the PR :)

Can you explain what complexities do you mean here?

Snapshot-based architecture: The running instance periodically writes a JSON snapshot file. Any second instance reads this file to display status, avoiding IPC complexity and keeping the first instance unmodified.

@jeregon1

jeregon1 commented Jul 1, 2026

Copy link
Copy Markdown
Author

Thank you for reviewing,

It's my first contribution to the project, so probably I don't understand it well enough so that I'm right on what I'm going to say.
But, thinking of a way to implement the status subcommand with AI I didn't know how to make the first instance answer to the second one (that's the IPC complexity I was referring).
So the option of the status snapshot looked simple and effective enough.

I'll really appreciate any feedback <3

@hovancik

hovancik commented Jul 3, 2026

Copy link
Copy Markdown
Owner

Ah, gotcha, you mean sending message from 1st to 2nd instance. That's right, we don't have that yet, but writing file every 10 seconds seems excessive.

I think we should use statusMessages.js to generate the cli status, there's a lot of logic already over there.

We need to decide: how are we going to map it? Do we want to use localized message or english?

What do you think?

@jeregon1

jeregon1 commented Jul 7, 2026

Copy link
Copy Markdown
Author

I believe this command's main purpose is to be used with the --json flag, i.e. people using this will be mainly for scripting purposes, as the person who created the #1628 stated.

In that case, I think it's not necessary to add localization.

And yes, I didn't notice the statusMessages.js file, maybe we could put all the logic for this subcommand there.

@hovancik

Copy link
Copy Markdown
Owner

So plan should be:

  • change statusMessages.js to also generate cli status message (not sure whether some abstraction or duplication would be better)
  • save to file when second instance asks for it and second instance reads it

Then we can nitpick about specific wording in messages

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants