Add submodules support on GitHub through graphql api

[Dynesshely]

📋 Description

Currently, more and more projects use git submodules to split the project architecture, leaving an almost empty main repository (almost only references to submodules)

However, when counting data such as repo size/code size/comments, shields does not take the data of submodules into consideration.

Currently, GitHub GraphQL Api can already query submodules under a warehouse.
As long as the recursive search (specifying the front depth) is required, a submodule tree of the warehouse can be constructed.
The shields (repo size, etc.) mentioned above can be more accurate. (Of course, we may have to verify that the repositories belong to the same owner)

Take my own repo for example:

[Dynesshely]

For some shields that can introduce this function, we can add (bool) includingSubmodules argument.

[chris48s]

A slight issue here is that the submodule object isn't a full repository object. It only exposes quite a limited number of properties.

https://docs.github.com/en/graphql/reference/objects#submodule

• branch
• gitUrl
• name
• nameRaw
• path
• pathRaw
• subprojectCommitOid

As far as I can tell, things like size, languages etc can't be fetched for all submodules in a single query, so we'd have to make a second round-trip to fetch the details for submodules. With the GraphQL API we could at least query the data for all submodules at once in a second query.

I think I'd want include_submodules to be an optional param which is off by default.

Which badges are you thinking this would apply to?

[Dynesshely]

A slight issue here is that the submodule object isn't a full repository object. It only exposes quite a limited number of properties.

https://docs.github.com/en/graphql/reference/objects#submodule

• branch
• gitUrl
• name
• nameRaw
• path
• pathRaw
• subprojectCommitOid

As far as I can tell, things like size, languages etc can't be fetched for all submodules in a single query, so we'd have to make a second round-trip to fetch the details for submodules. With the GraphQL API we could at least query the data for all submodules at once in a second query.

I think I'd want include_submodules to be an optional param which is off by default.

Which badges are you thinking this would apply to?

As you said, it does require a second query to get the exact information, but I think it is worth it. Of course, in order to relieve the pressure on the server, this attribute should be turned off by default.

I think this property can be applied to the following shield first:

• https://shields.io/badges/git-hub-code-size-in-bytes
• https://shields.io/badges/git-hub-repo-file-or-directory-count
• https://shields.io/badges/git-hub-repo-size
• https://shields.io/badges/git-hub-repo-stars

[chris48s]

• https://shields.io/badges/git-hub-code-size-in-bytes
• https://shields.io/badges/git-hub-repo-file-or-directory-count
• https://shields.io/badges/git-hub-repo-size

I think I agree with the first 3 👍

• https://shields.io/badges/git-hub-repo-stars

Not sure about stars. If I make a repo and pull in https://github.com/freeCodeCamp/freeCodeCamp as a submodule, my repo now has >300k stars? 😄

[Dynesshely]

Not sure about stars. If I make a repo and pull in https://github.com/freeCodeCamp/freeCodeCamp as a submodule, my repo now has >300k stars? 😄

We could only count submodules' stars when they are owned by same owner, which could be better.