feat: added support to set version dynamically based on the release

[abdullahwaheed]

Added support to read and set version of datadog RUM. Version is read from process.env.APP_VERSION, which is recently introduced in [tubular].

Ticket

[abdullahwaheed]

tested on sandbox RUM app locally

[iamsobanjaved]

Just one suggestion, rest looks good 👍

[iamsobanjaved]

Can we add the default value here if process.env.DATADOG_VERSION is undefined. This way we can remove DATADOG_VERSION from YAML files as it will be of no use.

[adamstankiewicz]

[curious] Were any alternatives to fetching version.json considered yet? I'm a bit concerned needing to fetch version.json at runtime as it's a network request users will need to resolve before the MFE is initialized/executed. While it wouldn't be an expensive network request to make, it still introduces a request waterfall where version.json needs to be fetched before DataDog and the rest of the MFE can be initialized.

For example, an alternative could be to modify the tubular scripts regarding FrontendBuilder to create a new, generic APP_VERSION environment variable passed to the npm run build similar to the environment variables defined in the app config. Then, the change for DatadogLoggingService would be to consume this new environment variable created/passed in tubular instead of introducing a network request to get the same data.

If we opted for this alternative approach, the only change for DatadogLoggingService would be updating the environment variable used from process.env.DATADOG_VERSION to the generic APP_VERSION; I don't think we'd want to hardcode DATADOG_VERSION in tubular per se, hence the suggestion of a generically named APP_VERSION instead).

See this diff for what the alternative tubular approach might look like to mitigate the need to fetch version.json. With those changes, when we iterate over app_config.items() to generate a list of environment variables to use with npm run build, APP_VERSION would also be passed where DatadogLoggingService could then access it.

If you still wanted the ability for consumers to override the version for DataDog, then DatadogLoggingService could do something like:

const datadogVersion = process.env.DATADOG_VERSION || process.env.APP_VERSION || '1.0.0';

...where a custom DATADOG_VERSION takes precedence over the generic APP_VERSION.

Curious to hear what you think about this alternative approach, primarily to not need to fetch the version.json file since that introduces a minor request waterfall that could impact frontend performance.

[adamstankiewicz]

nit: given the required config settings check is implemented above, the applicationId and clientToken properties probably don't need to fallback to an empty string since they should be expected to have a value at this point.

The other fallbacks to empty strings for the other properties still makes sense, though :)