Extensions build command is HARDCODING the NODE_ENV environment variable to: production

[sandinosaso]

Checklist

• I'm using the latest version of Directus
• There's no other issue that already describes the problem.
• I've completed all Troubleshooting Steps.

Describe the Bug

We build an extensions that get ENVs variable to DB connection based on the NODE_ENV variable so for example:
In test env we use SQLite, in local we use Mysql and in production another Mysql

The problem we are facing, is that when we are working either in test or locally we keep having the NODE_ENV variable with value production we found this PR that introduced this change: https://github.com/directus/directus/pull/7627/files

We where not sure why we were always getting production value for the NODE_ENV variable and the PR above is the why.

The solution could be to not Hardcode the value instead taking it from the ENV where it is being used

To Reproduce

Just create a hook and do a console.log('NODE_ENV', process.env.NODE_ENV)

Hosting Strategy

Self-Hosted (Docker Image)

[github-actions]

Linear: ENG-710

[paescuj]

I can well imagine that the reason for the hard-coded value is that it provides a bit of extra security and it can be assumed that extensions will eventually almost always run in a productive node environment and thus be tested in this context right away. (Maybe @rijkvanzanten / @nickrum can confirm or correct this)
In light of this assumption, I don't consider this an issue but I imagine we could make it configurable as a build option.

[peauc]

What happens if you build your extension in its un-minified form ?

[nickrum]

This was mainly done for App extensions because some libraries expect bundlers to replace process.env.NODE_ENV, which is not an issue with API extensions. It should be reasonably safe to assume that NODE_ENV is properly set when running an instance of Directus, so we might as well just remove the code that replaces it for API extensions.

[paescuj]

This was mainly done for App extensions because some libraries expect bundlers to replace process.env.NODE_ENV, which is not an issue with API extensions. It should be reasonably safe to assume that NODE_ENV is properly set when running an instance of Directus, so we might as well just remove the code that replaces it for API extensions.

I see! Thanks! So just to be sure, you're suggesting to remove it only for API extensions but keep it for App extensions?

[rijkvanzanten]

@paescuj Lets try to remove it from both if we can 👍🏻 Hopefully there's another way for the end-user to add it themselves on the app extensions side if it's required :) (Bit hard to explain why it exists, and only for some extension types in that other case)

[nickrum]

I see! Thanks! So just to be sure, you're suggesting to remove it only for API extensions but keep it for App extensions?

Exactly 👍

Hopefully there's another way for the end-user to add it themselves on the app extensions side if it's required

There is not because process.env is a Node-thing not supported by browsers. Keeping it without replacement will break extensions using libraries that rely on it (in fact, Vue uses it and recommends consuming bundlers to replace it). While those libraries shouldn't use it in the first place, there is not really much we can do about it. Vite replaces it, esbuild replaces it, so we should do it too 😁

[rijkvanzanten]

Copy that! Ty :)