Fix/bazel parser

[losmateusz1]

• Add variable definition parsing inside Module.bazel
• Add more verbose logs when unsupported configuration is found

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.43%. Comparing base (33f9795) to head (cd77d67).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #11826   +/-   ##
=========================================
  Coverage     58.43%   58.43%           
  Complexity     1809     1809           
=========================================
  Files           361      361           
  Lines         13499    13499           
  Branches       1383     1383           
=========================================
  Hits           7888     7888           
  Misses         5115     5115           
  Partials        496      496           

Flag	Coverage Δ
funTest-no-external-tools	30.37% <ø> (-0.03%)	⬇️
test-ubuntu-24.04	41.78% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sschuberth]

@nnobelis, please also have a look.

[sschuberth]

Commit message: Here, the first "Bazel" should be "bazel" (as it refers to the scope / directory name), and the second "bazel" should be "Bazel" (as it refers to the build system name) 😆

[sschuberth]

Also, please explain in the commit message what's the effect of adding variable parsing. Does it avoid an exception? Or does it provide more data now? What else?

[sschuberth]

The MODULE.bazel.lock files should not be deleted as part of this commit.

[sschuberth]

The code stats still look suspicious:

[losmateusz1]

in my opinion we shouldn't keep lock files in repository, as they are regenerated during tests anyway. After running all tests we are generating more lockfiles than those already in the repository, so I am not sure why we should keep those two specifically, they are not being used for anything in other tests

for now I just moved removals to separate commit, I thought that this is what you are requesting :)

[sschuberth]

I am not sure why we should keep those two specifically, they are not being used for anything in other tests

I believe they're need for getting reproducible results in tests even if new version of dependencies have been published, correct @nnobelis?

Anyway, even if removing them, that must be done in a separate commit with a dedicated rationale.

[losmateusz1]

it is in separate commit now, would you like me to remove it from here and add separate PR for the cleanup?

[sschuberth]

I would like to get @nnobelis's feedback first.