[Bug] constants.js: Access to environment variables is breaking cypress tests + storybook stories

[eidermaen]

Describe the bug
We are using cypress to write component tests for our apps. In some components we are using an internal utils library with shared logic. This library itself is using the monday sdk. When now writing tests for our components or creating stories, it might be that the sdk is initialized at some point, even though it is not directly used in the component.

Due to a change made in the constants.js in this PR our tests are now failing with the following error

TypeError: The following error originated from your test code, not from Cypress.

  > Cannot read properties of undefined (reading 'MONDAY_COM_PROTOCOL')

When Cypress detects uncaught errors originating from your test code it will automatically fail the current test.

Cypress could not associate this error to any specific test.

We dynamically generated a new test to display this failure.
    at <stack trace>

It seems as if the call to isNodeDevStageEnv() is working (even though process.env is accessed there as well) but the following call to process.env.MONDAY_COM_PROTOCOL is then failing because process.env is not defined.

Steps to reproduce

1. Embed the SDK in an app
2. Create a new react component and in there initialize the sdk (const monday = mondaySdk())
3. Create either a new storybook story or a cypress component test for the newly created component
4. Either run npx cypress run --headless --component, npx cypress open and navigate to the component test or npx storybook dev

Expected behavior
Either the component test should run successfully or the story should be loaded without any issues

Context and environment

• OS: mac
• sdk version: In our case tested with 0.4.12 but error should still occur also in latest version
• cypress version: 12.17.4
• storybook version: 7.0.22
• react version: 18.2.0

Additional information
Current workaround is setting process.env.NODE_ENV to test. This way isNodeDevStageEnv() returns false and the subsequent calls - which are producing the error - are not being made anymore.

I think the fix would just be to do optional chaining like process.env?.[key] or to extend the isNodeEnv() method to check for the existence of process.env.