refactor: Consolidate UI5 data directory resolution into resolveUi5DataDir

[d3xter666]

Introduces packages/project/lib/utils/dataDir.js with a single resolveUi5DataDir() utility that encapsulates the full resolution chain:

1. UI5_DATA_DIR environment variable
2. ui5DataDir from configuration file
3. Default: ~/.ui5

Removes the duplicate getUi5DataDir() function from packages/cli/lib/framework/utils.js and migrates its callers (createFrameworkResolverInstance, frameworkResolverResolveVersion) to use resolveUi5DataDir() directly.

Consolidates and enforces the new utility accross packages

[RandomByte]

I'm wondering whether we still need the fallbacks in https://github.com/UI5/cli/blob/refactor/resolve-ui5-data-dir/packages/project/lib/ui5Framework/AbstractResolver.js#L44 and https://github.com/UI5/cli/blob/refactor/resolve-ui5-data-dir/packages/project/lib/build/cache/CacheManager.js#L77 since we now always provide a ui5DataDir value

[d3xter666]

I'm wondering whether we still need the fallbacks in https://github.com/UI5/cli/blob/refactor/resolve-ui5-data-dir/packages/project/lib/ui5Framework/AbstractResolver.js#L44 and https://github.com/UI5/cli/blob/refactor/resolve-ui5-data-dir/packages/project/lib/build/cache/CacheManager.js#L77 since we now always provide a ui5DataDir value

I had the same concnerns!
However, I see a potential backwards incompatibility in this case.
The AbstractResolver.js itself is internal only, but Openui5Resolver, Sapui5Resolver, Sapui5MavenSnapshotResolver are exposed as public APIs and passing {ui5DataDir: undefined} to them will break the current behaviour i.e. new Sapui5MavenSnapshotResolver({ui5DataDir: undefined}).

Removing the ui5DataDir argument from the constructor can potentially solve this issue, but from backwards compatibility perspective, to me it seems more risky

[RandomByte]

I'm arguing to make it a required argument for AbstractResolver.

The current state in this PR is confusing IMHO: Passing {ui5DataDir: undefined} to CacheManager will properly resolve the directory from env and configuration. Passing the same to AbstractResolver will ignore env and configuration and simply use path.join(os.homedir(), ".ui5"). This makes me think that the two entities could end up working on different directories.

[d3xter666]

I'm arguing to make it a required argument for AbstractResolver.

The current state in this PR is confusing IMHO: Passing {ui5DataDir: undefined} to CacheManager will properly resolve the directory from env and configuration. Passing the same to AbstractResolver will ignore env and configuration and simply use path.join(os.homedir(), ".ui5"). This makes me think that the two entities could end up working on different directories.

Thank you @RandomByte !

I have tried to analyze the situation and how ui5DataDir evolves in the chain.
We have couple of scenarios: @ui5/cli command & API usage (i.e. @ui5/project/ui5Framework/*Resolver)

CLI

From CLI perspective, we have encapsulation and all the resolutions come from the newly introduced resolveUi5DataDir which resolves the same for all scenarios. In any of the CLI commands we explicitly provide ui5DataDir as an argument over the execution chain, but rather we rely on internal resolution and with this refactoring, this means resolveUi5DataDir() call.

API

The API perspective is a bit more complex and I will try to simplify it by couple of API calls to illustrate it clearer.

Resolver.resolveVersion({verions: 1.xxxx}) // ui5DataDir === undefined -> ~/.ui5

// resolveUi5DataDir() -> eventually can fallback to ~/.ui5, but before that will
// consider UI5_DATA_DIR and ui5.yaml configuration.
CacheManager.create();  // ui5DataDir === undefined

It is obvious that for the same default values for ui5DataDir we have different fallbacks. We need to align them!

With that refactoring, CacheManager.create() now supports the same fallback mechanism as AbstractResolver and it no longer resolves the ui5DataDir internally. Now as it is aligned with AbstractResolver, the resolution comes from the higher order component. In case of any AbstractResolver instance this is ui5Framework.enrichProjectGraph and for the CacheManager.create(), it is BuildContext.getCacheManager()

Here's the resolution: 9ac64b5

[RandomByte]

I'm sorry, but I think this doesn't address my concern. There are still two public APIs that resolve the data dir differently. It seems like you just moved the resolution from one internal class to another, which doesn't change the behavior for external consumers:

1. The ProjectBuilder class still internally resolves the data dir using the env-var + config-file fallback chain.
2. The AbstractResolver class still ignores env-var and config-file and simply falls back to ~/.ui5

Take note that CacheManager is not a public API.

As I said before, I think aligning this thoroughly might mean that we need to force consumers of all public APIs to always provide the data dir, which no internal fallback. This might be a bigger refactoring, which we might not want to tackle now.