Normally things that need to be in the dotenv file are configs that will not change frequently (like backend base url).
Totally agree.
Move these configs to a js file will let this more vulnerable to XSS attacks.
In the end, the job to do to perform an XSS attack is the same whether you use dotenv to compile your configuration to your JS or whether you serve a different JS file for these configurations. You are more vulnerable because there is a well structured config file instead of constants in a big bundled JS file.
And about restart the application, I will need to "restart" the application anyway, cause I will need to build the new modifications and deploy it.
I agree. There is no advantage related to this in what I am suggesting.
If you want to change some configurations and not dispatch a new build, these configurations cant be in the frontend base code.
I still agreed. Application configuration belongs to your deployment pipeline. Not to your front-end base code.
Following your suggestion, I will need to have two pipelines, one for deploy the config file and don't dispatch the build and the other to deploy the entire application ?.
No. My point is that application configuration should not be compiled into your main application bundle. An efficient pipeline has a build step that creates a reusable artifact (your compiled JS) that can be deployed / used in any deployment environment (dev, staging, e2e testing, prod, etc).
My point is: don't recompile your code once for every environment you need to deploy in. Have a basis that never changes (for a given commit), use configuration to target environment specificities.
In this setup, we do not need 2 pipelines. We need one job that deploys both at once (the files compiled by the build pipeline and the configuration file).
Maybe put these configs in a remote config or put this in a backend/serverless function is a better idea, no ?
What you are suggesting is totally a valid alternative to the file approach I am suggesting. It's a bit more work, but it is a valid approach. You would still need a "backend based URL" that differentiates between dev, staging and your other environments, but that would work fine.
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.
Totally agree.
In the end, the job to do to perform an XSS attack is the same whether you use dotenv to compile your configuration to your JS or whether you serve a different JS file for these configurations. You are more vulnerable because there is a well structured config file instead of constants in a big bundled JS file.
I agree. There is no advantage related to this in what I am suggesting.
I still agreed. Application configuration belongs to your deployment pipeline. Not to your front-end base code.
No. My point is that application configuration should not be compiled into your main application bundle. An efficient pipeline has a build step that creates a reusable artifact (your compiled JS) that can be deployed / used in any deployment environment (dev, staging, e2e testing, prod, etc).
My point is: don't recompile your code once for every environment you need to deploy in. Have a basis that never changes (for a given commit), use configuration to target environment specificities.
In this setup, we do not need 2 pipelines. We need one job that deploys both at once (the files compiled by the build pipeline and the configuration file).
What you are suggesting is totally a valid alternative to the file approach I am suggesting. It's a bit more work, but it is a valid approach. You would still need a "backend based URL" that differentiates between dev, staging and your other environments, but that would work fine.