[templates] Introduce layout service REST configuration name environment variable

[illiakovalenko]

• This PR follows the Contribution Guide
• Changelog updated

Description / Motivation

• Pulled changes from [nextjs][react][vue][angular] Add support for layout service REST configuration name #1527 - Introduces new environment variable for REST layout service
• Added override sxa-jss for nextjs-sxa addon
• Re-implemented concatEnv function, now it's mergeEnv and source file will override existing values and concat unique

Testing Details

• Unit Test Added
• Manual Test/Other - ran all the frameworks in connected mode and checked that custom layout service configuration name provided via environment variable is applied, verified mergeEnv functionality

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[ambrauer]

In general, looks great (just a couple comments). But looking through this, I wonder if we should make this a purely JSS config-based solution (and lose the .env values). The original PR depended on the .env values to supply the default value, but in this PR we have the fallback/default provided by the JSS config logic.

For nextjs-sxa, this would mean instead of a .env we could use a config plugin (e.g. /scripts/config/plugins/sxa.ts).

Considerations for removing the .env value:

• Environment variables should be something that would change per environment or deployment (yes, we have at least one offender of this rule already :)). I can't imagine a case where this one would.
• Not introducing another .env value (reducing the amount we already have is an internal goal)
• The nice thing about our JSS config architecture is that an environment variable can be used if absolutely necessary

If we do decide to go this route (and remove the .env vals), I think the .env concat > merge logic is a great improvement and should stay either way.

[illiakovalenko]

In general, looks great (just a couple comments). But looking through this, I wonder if we should make this a purely JSS config-based solution (and lose the .env values). The original PR depended on the .env values to supply the default value, but in this PR we have the fallback/default provided by the JSS config logic.

For nextjs-sxa, this would mean instead of a .env we could use a config plugin (e.g. /scripts/config/plugins/sxa.ts).

Considerations for removing the .env value:

• Environment variables should be something that would change per environment or deployment (yes, we have at least one offender of this rule already :)). I can't imagine a case where this one would.
• Not introducing another .env value (reducing the amount we already have is an internal goal)
• The nice thing about our JSS config architecture is that an environment variable can be used if absolutely necessary

If we do decide to go this route (and remove the .env vals), I think the .env concat > merge logic is a great improvement and should stay either way.

It's a great proposal! Right, for the future we can introduce more config based variables if we will need it (env vars not required to be added)
So, for nextjs, react I'm using config based variable, for the rest of frameworks I also decided to remove env variable even though we don't have plugins yet, but I think it's still fine

[ambrauer]

👍