Store Language Name, Version, and Requirements for npm, pnpm, and yarn

[kbukum1]

What are you trying to accomplish?

This PR adds functionality to detect and include the language name (Node.js) and its version for npm, pnpm, and yarn package managers.

Why?

• To accurately identify the runtime environment (Node.js) by using node -v to fetch the version directly.
• This ensures dependency updates are handled with the correct language version context, improving reliability in JavaScript-based ecosystems.

This change improves Dependabot's ability to work with JavaScript projects by explicitly detecting and documenting Node.js as the runtime language and its version.

---

Anything you want to highlight for special attention from reviewers?

• The implementation uses the node -v command to fetch the Node.js version at runtime. This approach is simple, reliable, and avoids relying on indirect metadata (e.g., volta or engines.node).
• Test coverage ensures that all three package managers (npm, pnpm, and yarn) work seamlessly with this addition.

---

How will you know you've accomplished your goal?

• Unit tests validate the language detection and version fetching logic.
• Manually testing against sample npm, pnpm, and yarn projects confirms the correct Node.js version is detected.
• Dependabot updates dependencies without issues when language-specific constraints are considered.

---

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[jonabc]

it's a little hard to see the functional changes amid all of the added logging. In the future if you're adding logging to otherwise untouched code, can you bundle it as a separate change/PR?

Re: the new logging - much of the added Dependabot::Logger.info output looks like debug information which can get noisy if it's always written to logging. Would it make sense to use Dependabot::Logger.debug to keep noise down in prod logs but still make it easy to toggle on when debugging?

[kbukum1]

it's a little hard to see the functional changes amid all of the added logging. In the future if you're adding logging to otherwise untouched code, can you bundle it as a separate change/PR?

Re: the new logging - much of the added Dependabot::Logger.info output looks like debug information which can get noisy if it's always written to logging. Would it make sense to use Dependabot::Logger.debug to keep noise down in prod logs but still make it easy to toggle on when debugging?

@jonabc
When monitoring metrics, it was challenging to identify which version was being used and what information was captured. This led me to believe that logging this general information properly at the info level would be helpful. It allows anyone investigating an issue to clearly see the package manager and language versions involved, potentially replicating the problem with the same versions. For this reason, I felt info was more appropriate than debug.

I also wanted to note that, in our investigations, errors related to run commands are often the hardest to diagnose because we lack proper logging for them. That’s why I’ve focused on adding logging, particularly around command execution.

Let me know if you think this could be approached differently!

[jonabc]

I don't have enough practical experience with dependabot-core to know whether my previous comments are valid. I'm still a little uncomfortable with the change but 🤷 the functional changes seem small and tested