Supporting independent versioning of modules inside a single repository

[itsdouges]

Hello! I've written a tool to help version modules deployed to the Deno registry (see: https://github.com/itsdouges/deno_changesets). It works. One friction point I have with the current deno_x setup is it seems impossible to version modules independently from one another as the version is dependent on the git tag, meaning they'll always be versioned together.

This is OK, but not as desirable as if it could be versioned independently for some use cases. Has there been any thoughts as to how we can enable versioning modules independently?

---

As a side I noticed there are hard limits to # of modules in a repo and owned by a user on Github... are these limits imposed by Github APIs?

[crowlKats]

Has there been any thoughts as to how we can enable versioning modules independently?

There has been no discussion around this yet; especially as it sounds like it would need a core change on how the registry works, this seems quite difficult

As a side I noticed there are hard limits to # of modules in a repo and owned by a user on Github... are these limits imposed by Github APIs?

These limits are set by us, unrelated to github APIs. This limit however can be increased for individual users; if you would like us to, please send an email to modules@deno.com.

[itsdouges]

Thanks for the info!

... especially as it sounds like it would need a core change on how the registry works ...

I think the registr versioning with git tags can still work. We could have a prefix for the module name? So for example if I were to version these modules independently:

• foo_bar@1.0.2 (minor) -> 1.1.0
• baz_qux@2.3.1 (major) -> 3.0.0

During a "release" it could create a git tag for each released module in the form of {module_name}@{version}:

• foo_bar@1.1.0
• baz_qux@3.0.0

And then the deno registry would pick it up and use it accordingly. If foo_bar is found as a prefix in a git tag it would scope the "bump" to only that folder. If there was no module name prefix found it would act as it does today (and version all sub modules).

It would be a bit tricky (error prone) to do this by hand as a consumer but that's where libraries can fill in the gaps (such as deno_changesets).