Adding @tomek and @atul as blocking to get at least one more set of eyes on this, although the rest of the stack prior to this diff still needs to be reviewed.

Re-requesting review since the entire stack for the new MessageTimestampTooltip has been pushed, and this diff was only amended to work with the changes made in D4434. Removing @ashoat since he already accepted the old code/has context on this issue and probably doesn't need to be a first-pass reviewer on this stack.

Put .messageTimestampTooltip CSS class in the useMemo on line 62 so it is memoized, per @jacek's feedback.

Un-modify --tool-tip-bg in theme.css. Since we want the MessageTimestampTooltip color to match MessageTooltip, we can just set background-color to --message-action-tooltip-bg, as done in line 44 of tooltip.css of this diff, since --message-action-tooltip-bg sets the color of MessageTooltip.

Abandoning, see D4481.

In D4434, there were certain changes made that made D4481 broken since ChatMessageList was refactored. This update brings ChatMessageList up to date and out of a broken state. Since this is the first in a stack of diffs that will resolve the timestamp bug (Linear issue here), it doesn't need to be landed yet since I plan on getting the rest of the diffs up. I have abandoned D4700 since those changes have been made as an update in here.

Accepting, assuming @atul's and my feedback will be addressed prior to landing.

In D4630#134917, @jon wrote:

if you're just running shellcheck, I can do something similar

I'm sure we could use whatever sequence of "non-frozen" endpoints to get the information we need, but differential.query gives it to us all in one go...given the logic is written using differential.query and this is a pretty low importance script, I think it's fine to leave as is.

This makes sense in conjunction with D4689, but I had some questions regarding that diff so will hold off on accepting this until that diff is accepted in case this one changes (I don't think it should, though, since my questions were only about the contents of the script, not its directory, etc.).

Separately, it might make review a bit easier if @atul could share an example of a generated shell script.

Minor changes (double-quoting).

This makes sense. Thanks for being thorough in your logic in the Linear issue, made this diff easier to review.

Just a basic review using ShellCheck. Will get it added to the CI soon, sorry for the delay!

Looks good!

Can you add a summary explaining the purpose or context for this diff?

Yeah, it just depends on how stringent future code reviewers want to be.

Yup, I agree. @ashoat suggested I resign in this case (since I had already stated it looks good to me, but I wanted one of you to take a look at it).

Resigning to put this on @atul and @palys-swm's queue.

Looks good!

Solved!

iOS build is failing, but that should be unrelated...planning changes to investigate

Address inline feedback:

• Replaced bash with sh
• Replaced all usages of . /bash/source-nvm.sh with . bash/source-nvm.sh. I'm not sure why this diff didn't revert the first time, I was wrong about that.

Removed executable bit from source-nvm.sh. Addressed rest of inline feedback in comments below.

Looks good!

It would appear so! :D

Looks good to me, but would like @atul or @palys-swm's input as well since this diff creates an entirely new component.

Looks good! Had IRL discussion with @varun about if we are going to specifically write installation instructions for Terraform or if we will just point the developer to the download link. I agree with his assessment: for the dev environment docs, since it's all Mac it's easy to document some brew install commands whereas in the services doc, it's harder to specify Linux/macOS/platform-specific instructions which the installation link covers in detail anyways.

That worked, thanks!

@ashoat I don't think the recording is loading? I'm getting a 404 Not Found:

bash-wise, looks good.

Adding @yayabosh as blocking to make sure the RegExp escape question gets resolved, but seems like if ESLint / Prettier don't want the escapes we can leave them out

Specify stable for Debian

Makes sense.

In D4477#127356, @ashoat wrote:

We don't use this script anymore, we're using Docker in production now. Probably would be best to just delete the script

accidentally hit accept, sorry. Will accept once this change is reverted.