[quote=“FichteFoll”]
[quote=“iamntz”]
One Repo per language[/quote]
Regarding one repository per language, I think there is a serious flaw in that concept: Default packages depend on one another, notably HTML and family. Since these dependencies are not linear (i.e. there is no hierarchial structure, all are on the same level), once can not simply move them to submodules without breaking otherwise atomic commits.
Otherwise I agree that splitting is more convenient for projects that stand on their own (own issues, easy to fork/clone, ability to promote different contributors for selected packages).
Maybe someone knows a solution for this?
.[/quote]
Dependencies. Ah, dependencies.
One monolithic repository or lots of little ones, dependencies are still an issue.
A maintainer who has a dependency on another project still needs to monitor changes and developments to the dependency. Only, the monolithic repository is going to make harder. Because to monitor a dependency a maintainer now needs subject themselves to notifications for changes to all the things, every pr, issue, every comment, commit, merge. People won’t do it. It becomes harder to monitor the things of interest.
Package dependency management is the only real solution. It may not be liked, it may not ever be done, it’s a good and solid solution.
Even a poor mans dependency management. Throw a sublime-package.json into every project.
{
"sublime/json-syntax",
"requires": {
"sublime/shell-syntax": "~1.0.0"
}
}
Have the tooling project I mention earlier deal with it. Semver all the way baby. Let version numbers go to 11.
Ideally the package bundler tool would use the github api and pull down the latest tags and do version resolving.
Or the tooling project can have a hardcoded release.json file which explicitly defines the tagged versions for the latest ST release, and dependencies just need to be monitored by maintainers.
Yay!