graphVerification external files bug

[jayden-ong]

Overview

When we run the frontend for the clean-architecture-visualizer project, there is a bug where external nodes show up as missing, even though they exist. There is also a bug where edges between two external nodes don't show up. There is also a problem with extracting the file context when the "from" node is a use case interactor or entity.

Proposed Changes

To allow all of the external nodes to show up, all of the external files are added to every use case, even if there isn't necessarily a connection between the use case and the file. For example, the useCaseGraph entity is added to the createFeature use case, even though one never invokes the other. This allows the node to show up and to signify that the nodes are not related, there are no arrows between the node and the rest of the nodes in the use case. The reason edges between external nodes don't show up is because the importFileName removes the file extension when the file extension is part of the unique identifier for file names. Without it, graphVerification doesn't detect any connections between two external files. To fix the bug where the edges don't show up, we check if the external file name contains the name of the import, so file extension does not play a factor.

Because there could be multiple files of the same type in a use case (three data access files for example), there could be multiple matching nodes when we look for violation nodes. To find the right one, we filter all candidates and check if they have a defined file context. This means that there is a line that references the "from" node file, signifying a violation.

The problem with extracting file context from a use case interactor and entity is that interactor files normally just contain "interactor" and not "usecaseinteractor" which is what file context is looking for. The same thing happens for "entities" and "entity". To fix this, there is a check in "fileAccess" that if the target is "useCaseInteractor", it will also accept "interactor" and if it is looking for "entity", it will also accept "entities".

...

Screenshots of your changes (if applicable)

Before: After:

How to Test & Review

(Help your reviewer by providing clear instructions on how to verify your changes. Include specific commands, edge cases to watch out for, or UI navigation paths.)

Type of Change

(Write an X or a brief description next to the type or types that best describe your changes.)

Type	Applies?
🚨 Breaking change (fix or feature that would cause existing functionality to change)
✨ New feature (non-breaking change that adds functionality)
🐛 Bug fix (non-breaking change that fixes an issue)	x
🎨 User interface change (change to user interface; provide screenshots)
♻️ Refactoring (internal change to codebase, without changing functionality)
🚦 Test update (change that only adds or modifies tests)	x
📚 Documentation update (change that only updates documentation)
📦 Dependency update (change that updates a dependency)
🔧 Internal (change that only affects developers or continuous integration)

Checklist

(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)

Before opening your pull request:

• [x ] I have performed a self-review of my changes.

  • Check that all changed files included in this pull request are intentional changes.
  • Check that all changes are relevant to the purpose of this pull request, as described above.

• [x ] I have added tests for my changes, if applicable.

  • This is required for all bug fixes and new features.

• [x ] I have updated the project documentation, if applicable.

  • This is required for new features.

• (Frontend) I have added/updated text in i18n JSON files for any new user-facing strings to support multilingual features.
  After opening your pull request:

• [ x] I have verified that the CI tests have passed.

• [ x] I have requested a review from a project maintainer, and a fellow student.

• Technical Debt: If temporary workarounds or "TODOs" were used, I have opened a tracking issue to address them properly.

  • Linked Issues:

Questions and Comments