[NO-TICKET] Update check for production to work on the server or client

[jack-ryan-nava-pbc]

Summary

• So yeah Kim had a really good point here and it bugged me that I didn't properly address it. So in this teeny tiny pr I'm trying to ease my conscience by setting this check to work on both the server and client. Note: this function will be called twice in some cases, since some of our code is both rendered statically at build time and on the client. But that should be ok so long as you aren't doing something like calling 'gatsby serve' locally (gatsby serve passes in 'production' as the node env).

How to test

1. Add to a random markdown page
2. Observe the warning in the console.

Checklist

• Prefixed the PR title with the Jira ticket number as [WNMGDS-####] Title or [NO-TICKET] if this is unticketed work.
• Selected appropriate Type (only one) label for this PR, if it is a breaking change, label should only be Type: Breaking
• Selected appropriate Impacts, multiple can be selected.
• Selected appropriate release milestone

[kim-cmsds]

Ok, this works! And my suggestion was that we don't necessarily need this urlUtils.ts file.

Looking at the line in question from the prior PR (https://github.com/CMSgov/design-system/pull/3566/files/52f815793cc009b6abd7c12b47c204fe04f74343..b49ea354b74f4a07063f0c9f61d892150a866fb4#diff-90039f0d04d02265cf24cce00452534e833da5f5de89aa9cca54397f2fa28106R75)...

It's possible to check in that component:

if ((!componentVariables || componentVariables.length == 0) && process.env.NODE_ENV !== 'production') {

[jack-ryan-nava-pbc]

Yes, totally could do this in component. I was trying to be proactive and make this a general utility since this is a thing we have to do not infrequently

[kim-cmsds]

Cool! Thanks for explaining your reasoning. That makes sense. What do you think about refactoring the below code to the following?

export function isProduction(): boolean {
  return process.env.NODE_ENV === 'production'
}

[jack-ryan-nava-pbc]

So there are functions that exclusively used client side, anything rendered with the useClient function will be client only, so I was thinking it made sense to preserve the client side check. I could be mistaken though.

[tamara-corbalt]

Hey, just weighing in here — I’m not totally sure how this utility will ultimately be used beyond its current (and only) invocation in CurrentThemeOptions, but if it ends up being called in both server and client contexts, the current version diverges a bit from other patterns I’ve seen in the codebase, which typically use typeof window === 'undefined' for client-side checks. Maybe worth aligning for consistency if we stick with this implementation?

[jack-ryan-nava-pbc]

@tamara-corbalt I have opinions about using a === with typeof. That aside, checking if window is falsy is fine in this case I think. If it's an empty string, undefined, null, or 0 then window doesn't exist in the way that we care about. We might have checks elsewhere, later on for production or not. I've used logic similar to this for analytics, which is a place where we tend to care about environment. We could also use this script to stop tracking New Relic locally for example, which maybe we should do.