chore: changing all env params to be required

[obecny]

all env params with defaults should be changed to required

[codecov]

Codecov Report

Merging #1328 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1328      +/-   ##
==========================================
- Coverage   92.29%   92.26%   -0.04%     
==========================================
  Files         180      178       -2     
  Lines        4452     4342     -110     
  Branches      928      896      -32     
==========================================
- Hits         4109     4006     -103     
+ Misses        343      336       -7     

Impacted Files	Coverage Δ
opentelemetry-web/src/WebTracerProvider.ts
opentelemetry-web/src/StackContextManager.ts
opentelemetry-web/src/types.ts
opentelemetry-web/src/utils.ts
...ntelemetry-web/src/enums/PerformanceTimingNames.ts
...sync-hooks/src/AbstractAsyncHooksContextManager.ts	96.49% <0.00%> (ø)
...ontext-async-hooks/src/AsyncHooksContextManager.ts	100.00% <0.00%> (ø)
...async-hooks/src/AsyncLocalStorageContextManager.ts	100.00% <0.00%> (ø)

[naseemkullah]

Just one question before moving forward with this:

do we:

• want a default value for the env var if the user does not set the env var? (as per current PR and current behaviour of getEnv())
• or do we actually want the values to be undefined if not user set, and then default values have to be dealt with in the various packages?

[obecny]

Just one question before moving forward with this:

do we:

• want a default value for the env var if the user does not set the env var? (as per current PR and current behaviour of getEnv())

Yes we want to have logic in one place, instead of keeping this in many places including frontend and backend as well as in contrib repo. You want to make sure the env params will be ready to use across all different plugins / platforms etc. That was the whole purpose of having one class for getting the env. without worry of platform, extra checking etc.. So that the same params will be interpreted the same way everywhere.

[naseemkullah]

Just one question before moving forward with this:
do we:

• want a default value for the env var if the user does not set the env var? (as per current PR and current behaviour of getEnv())

Yes we want to have logic in one place, instead of keeping this in many places including frontend and backend as well as in contrib repo. You want to make sure the env params will be ready to use across all different plugins / platforms etc. That was the whole purpose of having one class for getting the env. without worry of platform, extra checking etc.. So that the same params will be interpreted the same way everywhere.

Ah I see, thanks for confirming.

[mwear]

LGTM. I have one non-blocking question. How do we want precedence to work when there is in-code configuration and environment variable configuration. If we decided we wanted environment variable configuration to take precedence over in-code configuration having values be unset would be meaningful.

[obecny]

LGTM. I have one non-blocking question. How do we want precedence to work when there is in-code configuration and environment variable configuration. If we decided we wanted environment variable configuration to take precedence over in-code configuration having values be unset would be meaningful.

Not sure if we already have a strategy for that but If I were to decide I would say the user inputs will always take precedence over env variable - user variable (config input) should wins

[dyladan]

LGTM. I have one non-blocking question. How do we want precedence to work when there is in-code configuration and environment variable configuration. If we decided we wanted environment variable configuration to take precedence over in-code configuration having values be unset would be meaningful.

Not sure if we already have a strategy for that but If I were to decide I would say the user inputs will always take precedence over env variable - user variable (config input) should wins

Definitely agree in-code always takes precedence over env.