fix(project-access): check for files in srv folder treats directories as files and throws exception

[heimwege]

#2922

project-access checkFilesInSrvFolder currently throws an exception in case the CAP srv folder contains subfolders because those are currently being treated like files and readFiles dumps on folders.

@kjose90 would the proposed fix work for you?

[changeset-bot]

🦋 Changeset detected

Latest commit: 53012fb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 40 packages

Name	Type
@sap-ux/project-access	Patch
@sap-ux/abap-deploy-config-sub-generator	Patch
@sap-ux/abap-deploy-config-writer	Patch
@sap-ux/adp-flp-config-sub-generator	Patch
@sap-ux/adp-tooling	Patch
@sap-ux/annotation-generator	Patch
@sap-ux/app-config-writer	Patch
@sap-ux/cap-config-writer	Patch
@sap-ux/cards-editor-middleware	Patch
@sap-ux/cf-deploy-config-sub-generator	Patch
@sap-ux/cf-deploy-config-writer	Patch
@sap-ux/create	Patch
@sap-ux/environment-check	Patch
@sap-ux/fe-fpm-writer	Patch
@sap-ux/fiori-annotation-api	Patch
@sap-ux/fiori-generator-shared	Patch
@sap-ux/flp-config-inquirer	Patch
@sap-ux/flp-config-sub-generator	Patch
@sap-ux/launch-config	Patch
@sap-ux/mockserver-config-writer	Patch
@sap-ux/odata-service-inquirer	Patch
@sap-ux/odata-service-writer	Patch
@sap-ux/preview-middleware	Patch
@sap-ux/project-integrity	Patch
@sap-ux/telemetry	Patch
@sap-ux/ui5-application-inquirer	Patch
@sap-ux/ui5-library-reference-inquirer	Patch
@sap-ux/ui5-library-reference-sub-generator	Patch
@sap-ux/ui5-library-reference-writer	Patch
@sap-ux/ui5-library-writer	Patch
@sap-ux/fiori-elements-writer	Patch
@sap-ux/fiori-freestyle-writer	Patch
@sap-ux/fe-fpm-cli	Patch
@sap-ux/abap-deploy-config-inquirer	Patch
@sap-ux/deploy-config-generator-shared	Patch
@sap-ux/inquirer-common	Patch
@sap-ux/ui5-library-sub-generator	Patch
@sap-ux/generator-simple-fe	Patch
@sap-ux/cf-deploy-config-inquirer	Patch
@sap-ux/ui5-library-inquirer	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[heimwege]

@Klaus-Keller I refactored to the approach I would prefer because for me this would be more reusing what we already have instead of doing the same thing over again at a different place. Can you please check?

@kjose90 Any comment from your side?

[Klaus-Keller]

Hi @heimwege, while reviewing this pull request I found some issues with findBy() when used with memFs.

Here is what happened, I wanted to test the two scenarios for determining CAP project type using memFs.

1. The srv folder was there but has been deleted in memFs
2. There was no srv folder on disk but files in srv folder in memFs

While the first test was fine, the second test failed. Reason is, that findit2 uses fs.lstat to traverse paths, in case of srv being in memory, this throws an error here: https://github.com/andrewrk/node-findit/blob/44259da7851f4198714581d6fd7c89b256c2256d/index.js#L43.

However, the callback function passed to finder.on('end', ..) is still executed. So I thought, we could not immediately reject() in case an error occurs, but collect errors and filter out those, that are for missing files when they exist in memFs.

While debugging this, I found another issue with the code to filter changes:

    const filteredChanges = Object.keys(changes).filter(
        (f) =>
            fileNames.includes(basename(f)) ||
            extensionNames.includes(extname(f)) ||
            (fileNames.length === 0 && extensionNames.length === 0 && f.includes(root))

While your addition (fileNames.length === 0 && extensionNames.length === 0 && f.includes(root)) works, the other two cases fileNames.includes(basename(f)) and extensionNames.includes(extname(f)) do not consider the root path. This means, the result contains files from memFs, which are not inside the path or a subfolder of the path that has been searched for.
I fixed the issues I've found, which led to the fact, that function findBy() exceeded cognitive complexity of 15, which is a Sonar code smell. So I had to extract the finder.on('end'...) handling into an own function getFindResultOnEnd() 🙈.

As I've ended up spending quite some time on it, I took the freedom to commit the changes to this branch, if you disagree we can revert them:

f905921:

• tests for CAP projects with memFs
• tests for findBy() with memFs

2725963:

• ignore errors for files/folders that do not exist on physical file system but in memFs
• fix issues with files from memFs that or not inside the path the search was for
• remove type definition Finder in favor for findit2.d.ts, see fix(project-access): check for files in srv folder treats directories as files and throws exception #2923 (comment)

Please check the changes @heimwege and @kjose90.

[heimwege]

@Klaus-Keller did the tests run for you? I get a lot or errors with the current version of the branch

Seems like there was the well known windows vs. mac path separator issue. I enforced the path.posix.sep for the memFs check and at least the tests are now green.

[Klaus-Keller]

@Klaus-Keller did the tests run for you? I get a lot or errors with the current version of the branch

Seems like there was the well known windows vs. mac path separator issue. I enforced the path.posix.sep for the memFs check and at least the tests are now green.

Sorry, missed that. For me the tests run was green. Thanks for fix.

[Klaus-Keller]

Thanks @heimwege for looking into this.

• changes to check files in virtual folder look good
• changeset exists
• test coverage is good
• visual check and manual tests done

Approved from my side.

[Klaus-Keller]

@kjose90, please review this pull request.

[kjose90]

Thanks @heimwege. Changes looks great & tests to cover. ✅
Just a small example would be nice getMemFsChanges if its not too much work.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud