Fire alarm support

[brandenrodgers]

Description and Context

Relies on this LDL PR: HubSpot/hubspot-local-dev-lib#253

This is building on the discovery work that @b-ash did to support Fire Alarm warnings in the CLI. The goal here is to enable ourselves to be able to surface notifications to users on existing CLI versions. We'll be able to surface warnings without devs needing to update their CLI versions. The way I have it set up now, we can target specific CLI versions and also specific commands. This should give us the right amount of granularity. We should put some thought into how we might want to leverage this, because it will be difficult to make changes down the road. The real value in this is being able to target old CLI versions.

Rolling this out:

1. We release these changes, which includes some middleware to fetch fire alarms at the beginning of every command
2. From this CLI version and on, we'll be able to create Fire Alarm notifications that can target specific CLI versions and commands

Behavior:

• We use querySelector to target specific CLI commands.
  • A null value means target every command
  • "project upload" would only surface a warning if the dev runs hs project upload
  • "project upload::init" would surface a warning if the dev runs hs project upload or hs project init
• The query selector doesn't support numerical values, so I put the version targeting in the message body
  • Look at the comment that I left at the top of the file for an explanation of how it works

Open questions:

• How should we format these messages in the CLI output?
• Should I update the command targeting syntax to support targeting entire command buckets? (i.e. "project *")
  • Fire alarms support a severity. Should we change the styling for warnings vs outages? Maybe we could use a box around these messages (like in the update notification screenshot below) and then use the severity to determine the color of the box?
• Should devs be able to opt-out of these warnings via a config setting?
• Should we attempt to limit the frequency that we show devs these warnings? What if a dev is seeing these on every single command they run. Would that get annoying?

Screenshots

Here's my rough first draft just to show what this can look like:

The messages mainly have a title, severity, and message that we should be surfacing. I'm not currently doing anything with the severity field.

Another thing to consider is that we have an existing update notification system. We'll have to think about how this interacts with that:

TODO

Who to Notify

[brandenrodgers]

latest screenshot example:

[camden11]

Before I review, did something weird happen with prettier? Looks like there's a lot of files changed that are just spacing / style changes

[joe-yeager]

Before I review, did something weird happen with prettier? Looks like there's a lot of files changed that are just spacing / style changes

@camden11 It looks like it, because none of these showed as linting errors and all my builds were clean for inlining the i18n variables. 🤔

[joe-yeager]

@brandenrodgers I just fixed the linting errors in a separate PR if you pull main they should go away

[joe-yeager]

The logic LGTM, just a non-blocking question

[camden11]

Hmm do you think we'll never want to target beta versions? I could see it being helpful occasionally. Maybe we could exclude them from the more generalized targeting (with * and >= etc) but let you target them by specifying the exact version?

[brandenrodgers]

I like that idea. This was somewhat of an arbitrary call on my part. I'll add in some support for exact version targeting for beta versions.

[camden11]

Should I update the command targeting syntax to support targeting entire command buckets? (i.e. "project *")

Not sure if you already did this (the logic looked like this would work) but I could definitely see a scenario where we want to target buckets. At the very least, the project bucket

[brandenrodgers]

Not sure if you already did this (the logic looked like this would work) but I could definitely see a scenario where we want to target buckets. At the very least, the project bucket

@camden11 yeah agreed. The logic does support it, so I think we should be all set. The way you'd do it is by specifying the bucket (e.g. hs project). I considered making it more intentional, like hs project *, but that felt like it would be overkill and would just complicate the logic.