Clarity on benefits of using the plugin.

[ckipp01]

I got an email with a couple useful questions that I figured I'd post here so others could also benefit from the answers.

If you already have scala steward raising regular PRs, what's the main value submitting dependency alerts to GitHub provides?

So these two tools are quite different. Scala Steward helps keep your project up to date by sending in PRs for outdated dependencies and also running migrations via Scalafix that might be tied to those new versions. mill-github-dependency-graph has no concept of "outdated" dependencies, but rather it takes your full dependency list and submits it to GitHub so that it can both be viewable under your Insights tab and also so that if enabled, you can get vulnerability alerts send to you about those dependencies.

In the readme if you can explain the value it could get more users. They might be new to GitHub dependency graphs like me. I'm almost prepared to raise a PR for us to use it at work on Monday - sounds very sensible.

Sure I'll try to make this clearer in the README.

The second thing is about the external module mill import - I haven't looked into it yet, but maybe it can be told to get latest versions (like how npm does with semver ^~ syntax, or even ::latest if that's a mill thing?). The examples have mill-github-dependency-graph_mill0.10:0.0.9, but I see you have 0.10.0 out. If this is possible, it could reduce toil in updating docs to point to latest versions.

Regarding using the latest, I don't believe Mill supports this. Even if it did, I wouldn't recommend using it. In the future this will be abstracted away by a GitHub action. I have a draft pr here which when merged should offer you to instead just include the action, and then the version will sort of be abstracted away from you. The weird syntax you mentioned was actually my mistake. That's a mill plugin-ism. Mill will will for a plugin artifact ending in _mill<version>. But if you instead use :: it will automatically pull in the one it needs. I've updated the README to reflect this.

[james-s-w-clark]

@ckipp01 Thanks for raising this in a more public manner. Nice to see the Discussions feature being used.

---

For the first point, I was more wondering about "what action will this tool encourage me to take?". I understand the difference between the tools; I'll try to illustrate my question in more detail.
So is the value in submitting the dependencies to Github the following? :

1. You can let owners of your dependencies know that there are vulnerabilities
2. You (or Scala steward) can then update those dependancies to non-vulnerable versions, when they are available

I was thinking that if you already have scala steward raising regular updates, then most of the value is from point 1 (point 2 would already happen, automatically). Does that make more sense?

I guess another question is "What insights does Github insights provide, other than vulnerabilities?"

---

Upcoming action sounds great, nice work :)

I guess the non-action way of running might be useful to keep around in the readme for e.g. Gitlab/Bitbucket users doing stuff in CI.
I'm thinking of this because I recently saw a PR with this kind of concern:

Not all OS Projects are using GitHub and have the benefit of using
GitHub Actions. With this changes the Wrapper-Validation-Action
is executable on its own. It will use command line options for
configuration instead of GitHub Action Inputs.

[ckipp01]

You can let owners of your dependencies know that there are vulnerabilities

Correct, the main point here being either open source library maintainers or individuals that have applications on GitHub can get vulnerability alerts right in GitHub.

I was thinking that if you already have scala steward raising regular updates, then most of the value is from point 1 (point 2 would already happen, automatically). Does that make more sense?

👍🏼 yup correct

I guess another question is "What insights does Github insights provide, other than vulnerabilities?"

I think right now, not a ton. The snapshot that is being given actually has quite a bit more info about direct vs indirect and other metadata about your dependency tree, but doesn't really show it. The public API is quite new for this, so it's a possibility that the UI for this will be improved in the future, and maybe the benefit increased.

I guess the non-action way of running might be useful to keep around in the readme for e.g. Gitlab/Bitbucket users doing stuff in CI.

All this plugin does is extract the dependencies and submit them to GitHub, so the core functionality of this plugin relies on GitHub. With that being said, you still can generate your manifests with this plugin if you want in your local or another CI environment as outlined at the bottom. I just don't think it'll be that useful since the format is the manifest format of GitHub.

[james-s-w-clark]

I just raised a Scala Steward issue to try and learn more about why some dependencies didn't update for us. If some had vulnerabilities, your new tool would have helped us be more alert. So, I can see value for Enterprise, not just OSS projects/individuals! 👏

Ah yeah good point about it being very Github focused😁 It will be cool to see what Github adds to make Insights spicier.

Thanks again for making this :)

Nitpick: title of this discussion could be updated now we share an understanding

[ckipp01]

It might be useful to you, but in a corporate environment you could also use something like https://github.com/albuch/sbt-dependency-check, although I don't know if there is a mill plugin for it.

[james-s-w-clark]

It might be useful to you, but in a corporate environment you could also use something like https://github.com/albuch/sbt-dependency-check, although I don't know if there is a mill plugin for it.

Thanks for the suggestion. Searching for "sbt-dependency-check" "mill" only brings up if there's a query if there is such a thing, but I can't see the thread in Mill's Gitter; I guess it does not exist.