fix: Improve module resolution

[matz3]

This solves issues where some detections did not work properly due to
the way dependencies were resolved.

When using relative imports, the module resolution was working, but when
for example importing a control from a test, the complete namespace is
used, but the corresponding JS file was not found.

This change ensures that JS files are resolved and also that the types
for a framework library are loaded when it is linted.

[d3xter666]

LGTM, but it seems coverage needs to be either improved or decreased a bit

[matz3]

I checked the difference and in SourceFileLinter.ts there is now less code covered in analyzeControlRendererDeclaration, as it takes a different path for the fixed case.

@d3xter666 do you know whether there is still a case that needs the handling in here?

ui5-linter/src/linter/ui5Types/SourceFileLinter.ts

Lines 315 to 331 in e9a5812

	// Check all exports
	moduleExportsSymbols?.forEach((exportSymbol) => {
	// Note: getAliasedSymbol fails when called with a symbol that isn't an alias
	let symbol = exportSymbol;
	if (exportSymbol.flags & SymbolFlags.TypeAlias) {
	// Export could be a "default", so we need to get the real reference of the export symbol
	symbol = this.checker.getAliasedSymbol(exportSymbol);
	}
	symbol?.getDeclarations()?.forEach((declaration) => {
	if (ts.isVariableDeclaration(declaration) && declaration.initializer) {
	this.analyzeControlRendererInternals(declaration.initializer);
	} else if (ts.isExportAssignment(declaration) && declaration.expression) {
	this.analyzeControlRendererInternals(declaration.expression);
	}
	});
	});

[d3xter666]

I checked the difference and in SourceFileLinter.ts there is now less code covered in analyzeControlRendererDeclaration, as it takes a different path for the fixed case.

@d3xter666 do you know whether there is still a case that needs the handling in here?

ui5-linter/src/linter/ui5Types/SourceFileLinter.ts

Lines 315 to 331 in e9a5812

	// Check all exports
	moduleExportsSymbols?.forEach((exportSymbol) => {
	// Note: getAliasedSymbol fails when called with a symbol that isn't an alias
	let symbol = exportSymbol;
	if (exportSymbol.flags & SymbolFlags.TypeAlias) {
	// Export could be a "default", so we need to get the real reference of the export symbol
	symbol = this.checker.getAliasedSymbol(exportSymbol);
	}
	symbol?.getDeclarations()?.forEach((declaration) => {
	if (ts.isVariableDeclaration(declaration) && declaration.initializer) {
	this.analyzeControlRendererInternals(declaration.initializer);
	} else if (ts.isExportAssignment(declaration) && declaration.expression) {
	this.analyzeControlRendererInternals(declaration.expression);
	}
	});
	});

It seems that this test/file test/fixtures/linter/projects/sap.f/src/sap/f/ProductSwitch.js
does not go through the moduleExportsSymbols... loop anymore. It's resolved here:
https://github.com/SAP/ui5-linter/blob/main/src/linter/ui5Types/SourceFileLinter.ts#L286

I believe this is caused by the new namespace resolve logic in here and also the conditional inclusion of the .d.ts files... I'm starting to question whether we need this custom module resolution logic anymore. But I suppose there might be cases where we intentionally might include the .d.ts files and then, we'll definitely need that.

Edit: Just checked it. Removed this section https://github.com/SAP/ui5-linter/blob/main/src/linter/ui5Types/SourceFileLinter.ts#L288-L332 and the tests are green. Also checked the sap.f and sap.m libs. Nothing suspicious there, too. Then it seems to be safe to remove this whole section

[matz3]

@d3xter666 thanks a lot 👍🏻 Then I'll go ahead with that. We can still revert it in case we encounter some relevant cases again.