Creating Environment Variables Manager

[marceloadsj]

Hey, hello @supnate.

I'm a big fan of your work on rekit and rekit-studio, its simply amazing. So I decided to give some help to evolve certain features that I would like to have, one of them, the environment variable manager.

What do you think about this?

Preview (WIP):

[supnate]

Hey, thanks @marceloadsj ,

This really looks great! In my mind Rekit Studio aims to visualize anything that could be visualized. Such as DepsManager, user may don't need to know npm behind, such as WebpackManager, user may don't need to know Webpack behind (though not done). Then user could be more focused on business logic rather than have to know unnecessary build/config details.

So, visualizing environment variables is a great idea for me. One point is variables list may need to depend on build configurations like 'development', 'dist', 'demo' for Rekit Studio. It seems should be part of visualization of build configurations(webpack config here).

However, you could just implement environment variables config UI first but keep build config in mind.

Looking forward to see your progress and feel free to contact me if need any help!

[marceloadsj]

Nice @supnate.

The idea of grouping configurations of same context (all build related, all deps related) is really good. I'm using the deps structure as reference to create the env vars component/endpoints, but we can group it later.

About the Webpack Manager screen, I could not imagine how easy and readable it would be while providing control functionality and configuration flexibility. Have you thought of providing certain more specific functions in this screen, and an "advanced / edit source" mode? (For example: a switch control to change from LESS <-> SASS, but for more control, click to edit the source).

Some ideas that I have about the Env Manager (or "env section" inside Webpack/Build Manager) are:

• Unused Env Vars: Show Env Vars registered in ".env" file but not used in any place of code;
• Unregistered Env Vars: Show vars that exists in code but was not registered in ".env" file;

What do you think?

If anyone has some ideas about the subject that you can share with us, post here in the comments. :-)

[supnate]

A general WebpackManager will be complicated we can just create EnvManager first. But we can involve build config concept now. Like there's a dropdown to show a list of build config names(development, production, demo, test, etc). Then the env files could be development.env,demo.env, etc.

Detecting unused/unregistered env vars is a good idea. But that may be impossible to full coverage all scenarios like if user uses env var via variables. We can just leave it on user's own.

For webpack manager UI of LESS, SASS, my idea is to provide Loader config list. User could add a loader to support a new resource type with form UI for its options. User just add/remove a loader to enable/disable a resource type support. LESS and SASS doesn't conflict from technical perspective.

[iamzjohn]

Hi @supnate about your last comment I guess the dotenv files should start with .env instead of ending with it, that way is easier to ignore on git and most projects use that structure.

and I also like the idea of having a Env Manager and would like to help

[marceloadsj]

Okay, I will work on EnvManager to accepts multiple .env files, and to accept the ability of add/edit/remove vars from these lists.

To the "detect" idea, I will study some ways to do it like, for ex:

• using a regex search on entire project to try to detect the env vars use;
• inject a "Proxy" on "process.env" to check if are touched at some time (development only);
• add a context menu option to set env var into .js files and control it;

I think this feature is good because here at work, we have a really big project and our build process sometimes fails because unset env vars. But we can study later if is a nice feature to integrate into rekit-studio or to put into some other library.

This new project works in an integration of dotenv with multiple .env files, the idea is so good, can inspire us: https://github.com/kerimdzhanov/dotenv-flow

[marceloadsj]

Hi, sorry the delay to publish some updates here.

I've worked on the initial phase of EnvVar (load and show in tables), heres a sneak peek of the result so far.

To the next step, I will work on put the add/edit/remove features on .env files, and trigger build update after it. My fork for those who want to follow the work: https://github.com/marceloadsj/rekit

[supnate]

Hi @marceloadsj , thanks for the update, it looks perfect!

Glad to see that variables are divided into General and Local. That's really a question in my mind. I've not used dotenv before, after looking at it I realized its env variables seems to be only used locally. But some env variables like NODE_ENV should be shared via git repo. So this seems to be a good practice.

One suggestion is should we use a dropdown list to switch "config set" like production, development, etc. So that the UI could be more clean and easy to extend.

Thanks!

[marceloadsj]

Sorry the delay, I'm really busy in my fulltime job. >_< This week I send a PR, at least to visualize. As next step I evolve it adding create, edit and delete. :)

Tks!

[supnate]

Hey @marceloadsj , thanks for the update. No problem for the time. Just note that the current master branch is under heavy refactoring so it might not work. You can use branch 2.x for the feature.