I haven't used yargs in a long time simply because our backend code is written in Python and Go has become my language of choice for one-off CLI tools. From that point of view, take whatever I say with a grain of salt because my language choices mean I am not a Fauda user by default.
That said, I have spent a lot of time in my life giving devops support to development teams that developed entirely in javascript. These are the experiences that made me wary of libraries like dotenv.
Even in javascript, i really dislike yargs - it just so happens that that's the library that I'm (unfortunately) most familiar with. Would be happy to switch to something like Fauda.
Your idea of a debug mode is fantastic. Some suggestions of different flavors:
It is valuable to know how a given invocation of my-app is configured, complete with values from the command line. Maybe a command like fauda inspect <my-app invocation taken from output of ps command>?
If a config value came from a file, would be nice to know the file path.
If a config value came from an environment variable, would be nice to know the env var name.
If a config value came from the CLI, maybe a snippet of the invocation with the argument highlighted?
To build sympathy for this use case, imagine you know almost nothing about the application. You are trying to debug some error message from your production logs by shelling into the server/container running that application. Once you are in, you want to know as quickly as possible:
how the application was invoked
what parameters it is using
If the application is using Fauda and I can use Fauda to get this information easily, I would forever recommend it to all JS developers I know.
I like the idea of having a fauda inspect. It could be a non-intrusive way to debug an already running Fauda-configured app.
I believe this could end up in unpredictable results though. The configuration file or the environment variables might have changed since the app has started, and fauda inspect could return values that don't reflect the startup app's configuration.
I think this could work if we enabled some communication between a Fauda-configured app and fauda inspect (e.g. socket). However, this would quickly add complexity to the current implementation. 😅
Do you see any other approaches that could allow fauda inspect to inspect an already running app?
You know, I need to retract my previous statement about Viper (github.com/spf13/viper). Used it this weekend to build a command line tool in Go, and I found it to be quite useful.
When someone installs that tool, they get access to a bugout binary. They can initialize a config file using bugout state init. The approach I've taken to inspecting state is bugout state current. This shows the config file path as well as the current config key-value pairs.
It's nowhere near as comprehensive as what Fauda allows you to do, but it suggests a different approach than a live Fauda socket (which, as you rightly pointed out, is way too much complexity). Instead, you can just write (atomically) Fauda state into a tempfile and read the most recent state from that file on fauda inspect.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I haven't used
yargsin a long time simply because our backend code is written in Python and Go has become my language of choice for one-off CLI tools. From that point of view, take whatever I say with a grain of salt because my language choices mean I am not a Fauda user by default.That said, I have spent a lot of time in my life giving devops support to development teams that developed entirely in javascript. These are the experiences that made me wary of libraries like
dotenv.Even in javascript, i really dislike
yargs- it just so happens that that's the library that I'm (unfortunately) most familiar with. Would be happy to switch to something like Fauda.Your idea of a debug mode is fantastic. Some suggestions of different flavors:
It is valuable to know how a given invocation of
my-appis configured, complete with values from the command line. Maybe a command likefauda inspect <my-app invocation taken from output of ps command>?If a config value came from a file, would be nice to know the file path.
If a config value came from an environment variable, would be nice to know the env var name.
If a config value came from the CLI, maybe a snippet of the invocation with the argument highlighted?
To build sympathy for this use case, imagine you know almost nothing about the application. You are trying to debug some error message from your production logs by shelling into the server/container running that application. Once you are in, you want to know as quickly as possible:
how the application was invoked
what parameters it is using
If the application is using Fauda and I can use Fauda to get this information easily, I would forever recommend it to all JS developers I know.
Thanks for the feedback!
I like the idea of having a
fauda inspect. It could be a non-intrusive way to debug an already running Fauda-configured app.I believe this could end up in unpredictable results though. The configuration file or the environment variables might have changed since the app has started, and
fauda inspectcould return values that don't reflect the startup app's configuration.I think this could work if we enabled some communication between a Fauda-configured app and
fauda inspect(e.g. socket). However, this would quickly add complexity to the current implementation. 😅Do you see any other approaches that could allow
fauda inspectto inspect an already running app?You know, I need to retract my previous statement about Viper (github.com/spf13/viper). Used it this weekend to build a command line tool in Go, and I found it to be quite useful.
This is the tool: github.com/bugout-dev/bugout-go
When someone installs that tool, they get access to a
bugoutbinary. They can initialize a config file usingbugout state init. The approach I've taken to inspecting state isbugout state current. This shows the config file path as well as the current config key-value pairs.It's nowhere near as comprehensive as what Fauda allows you to do, but it suggests a different approach than a live Fauda socket (which, as you rightly pointed out, is way too much complexity). Instead, you can just write (atomically) Fauda state into a tempfile and read the most recent state from that file on
fauda inspect.