RHDHBUGS-2776: Clarify NODE_ENV environment variable in Extensions procedure#2249
RHDHBUGS-2776: Clarify NODE_ENV environment variable in Extensions procedure#2249themr0c wants to merge 6 commits into
Conversation
themr0c
added
Peer review needed 📖
Technical review needed 🔩
PR Build ResultsBuild passed -- 34/34 titles | 68s Content Quality AssessmentCQA Report
SummaryChecks: 19 total, 19 pass, 0 fail 19 checks: 19 pass, 0 fail Run Updated 2026-06-02 06:48:58 UTC |
PatAKnight
left a comment
PatAKnight
left a comment
There was a problem hiding this comment.
Just some in-line comments and then a couple more additional comments.
First, I think we should mention somewhere that the default is NODE_ENV=production.
Second, we seem to be included additional things that aren't specific to the Extensions plugins, i.e. logging, caching. I would either outright remove them and put them in a more generic snip-node-env-developement or just rename the file entirely and aim to make this more generic.
Address review feedback: - State default NODE_ENV=production - Clarify Extensions uses NODE_ENV for UI-driven config file updates, not true runtime installation (restarts still required) - Remove unverified claim about configuration validation relaxation - Remove vague logging/caching side-effects - Add unsupported-in-production statement Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
themr0c
added
Technical review done ⛅
|
|
||
| [IMPORTANT] | ||
| ==== | ||
| By default, `NODE_ENV` is set to `production`. |
There was a problem hiding this comment.
@PatAKnight Do you know if this is explicitly set, or inferred in the absence of having NODE_ENV set to something else? To me, there's a difference between having a visible NODE_ENV = production in a config or not seeing it, and RHDH assuming behavior since no overriding value is present, but both could be considered defaults.
Is that distinction worth considering as part of this change? or am I overthinking it?
There was a problem hiding this comment.
When we got a question about Node_Env which led to this Jira, they wanted to know if they needed to set it to production to match their intended usage, and the only reference in the docs for Node_Env was in this guide, which is focused on how it affects the Extensions catalog.
When they looked through our code, they found this: https://github.com/redhat-developer/rhdh-plugins/blob/main/workspaces/extensions/plugins/extensions-backend/src/router.ts#L299 which injects a default of Development.
There was a problem hiding this comment.
... But then the step in the procedure is not necessary. How do you plan top move forward?
- Keep
developmentas default => rewrite docs accordingly. - Set
productionas default.
There was a problem hiding this comment.
I've been reviewing a similar PR and I see two supported scenarios:
-
A running dev instance (NODE_ENV=development) of RHDH that can be shared among other developers
I think NODE_ENV needs to be set by the customers so they can decide whether to run onproductionordevelopment. If unset, it might default to 'undefined'. Our e2e tests show how it's set for helm and operator deployments. -
RHDH Local which is single use (always set to NODE_ENV=development)
There was a problem hiding this comment.
Maybe we can combine this effort under the other PR which re-orgs the information for better flow.
We can have an overview paragraph to clarify what dev environments we support (deployed and single-use) and how NODE_ENV is used to distinguish runtime behaviour for certain features
There was a problem hiding this comment.
OK, then logically I should close this PR, link https://redhat.atlassian.net/browse/RHDHBUGS-2776 to https://redhat.atlassian.net/browse/RHDHBUGS-2241, and reassign https://redhat.atlassian.net/browse/RHDHBUGS-2776 to @Gerry-Forde. I ask @Gerry-Forde.
There was a problem hiding this comment.
@mattreid, I went looking and it seems like you are right. We do not set this explicitly set this anywhere. I could have sworn that we did set NODE_ENV=production but I am not seeing it anywhere. Might have been that I was thinking the inverse was true since RHDH Local sets NODE_ENV=development
|
In the same guide, it also mentions updating compose.yaml, which might not be needed anymore, but I'll have to defer to someone more technical. It may not have always been present, but rhdh-local's default.env sets Node_Env to Development. Would it also need to be set in compose, or if set in the environment variables, is that sufficient and that step is now redundant? Edit: I created https://redhat.atlassian.net/browse/RHDHBUGS-3305 for this. |
|
6 participants
Version(s): 1.9, 1.10
Issue: https://redhat.atlassian.net/browse/RHDHBUGS-2776
Preview: https://redhat-developer.github.io/red-hat-developers-documentation-rhdh/pr-2249/extend_installing-and-viewing-plugins-in-rhdh/#manage-plugins-by-using-extensions_extensions-in-rhdh (6.5.2)
Summary
snip-node-env-development-extensions-note.adoc) explaining whyNODE_ENV=developmentis required for Extensions, what it controls (config validation leniency, logging/caching behavior), and the trade-off of running it in productionproc-configure-rhdh-to-install-plugins-by-using-extensions.adoc(Operator CR and Helm values sections)Test plan
extend_installing-and-viewing-plugins-in-rhdh🤖 Generated with Claude Code
Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com