fix: ensure project names are readable in dark terminals

[rgrove]

Description

In terminals using a color scheme with a dark background, project names could end up being unreadable because one of the hard-coded background colors used for project names was black. Replacing black with blue solves this problem while also ensuring that project names remain readable in terminals with light backgrounds.

This mitigates an issue that's described in the comments of #6481, although it doesn't implement fully customizable colors, which is the main topic of that issue.

After:

Before:

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.

There doesn't seem to be any existing test coverage for the colors defined in formatProjectName(). It's not immediately obvious to me how I might add coverage, so pointers are welcome!

• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

There's one pre-existing test failure that also occurs on main. It's unrelated to this change:

 FAIL  test/browser-multiple.test.ts > automatically assigns the port
AssertionError: expected [ 'http://localhost:63316/', 'http://localhost:63317/' ] to include 'http://localhost:63315/'
 ❯ test/browser-multiple.test.ts:33:16
     31|   expect(spy).not.toHaveBeenCalled()
     32|   expect(stderr).not.toContain('is in use, trying another one...')
     33|   expect(urls).toContain('http://localhost:63315/')
       |                ^
     34|   expect(urls).toContain('http://localhost:63316/')
     35| })

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[netlify]

✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	1d16da8
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/67982f6fb7f14900083fd5ac
😎 Deploy Preview	https://deploy-preview-7371--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[AriPerkkio]

Isn't the bug here that c.black doesn't use proper background color? It should have some light background color, so that it would be visible in both light and dark backgrounds. c.inverse below should do that.

[rgrove]

I'm not sure I understand the feedback.

My understanding is that c.inverse() causes background colors to become foreground colors and vice versa, but since we're not setting separate background and foreground colors here, the result of c.inverse(c.black('text')) is a black background with text that's the color of the terminal's default background color.

In a terminal with a light background, this is likely to be readable because it will result in light text on black. In a terminal with a dark background, this is unlikely to be readable because it will result in dark text on black.

I've fixed this by using blue instead of black, because blue as a background color is more likely to be readable with both light and dark text (though it's still not guaranteed, since it depends on the specific color scheme in use in the terminal).

An alternative approach would be to define explicit colors for both the background and the foreground, in which case we would no longer need to use c.inverse(). Is this what you're suggesting, or would you like to see something else?