move away from gitmodules entirely?

[Pomax]

git submodules always point at HEAD, leading to potential code changes between subsequent installs, including potentially breaking changes - A package.json is already being used, so it would make a lot of sense to replace each submodules with a devDependency entry that points to the module's git repo, and relying on npm install instead. Then each dependency that follows the modern npm+semver convention can be switched over to a normal dependency instead of an unmanaged code checkout and it would become possible to use brackets itself as an easily imported resource in larger projects.

[ficristo]

Related discussion #12006

[Pomax]

heh, last activity literally a year ago. Time to revive it?

[zaggino]

"git submodules always point at HEAD..." since when? while Im in for using npm as much as we can, your statement is not based on truth

[Pomax]

git submodules always point to whatever HEAD is when you set them up (as a detached HEAD locally), and also always fast-forward to whatever HEAD is when you run git submodules update --init --recursive because that's what the command does: submodules don't peg a specific commit in perpetuity (see https://git-scm.com/book/en/v2/Git-Tools-Submodules) so anyone who runs a submodules update can get wildly problematic new versions to work with.

Unlike with an npm dependency for a specific git repo pegged to a specific commit (using @ notation), which is always the same no matter how much you type npm install

[zaggino]

Our submodules point to specific commits:

and we never ever had problems like you describe.

[Pomax]

perhaps not, but we did yesterday in our fork of brackets (mozilla/brackets) where we use brackets as code editor inside a larger project (an online IDE called thimble). There was a need to use git submodules update --init --recursive and this raised concerns over git submodules technically even allowing, not even necessarily causing, versioning-induced bugs, whereas npm dependency management won't even allow this because you can't force a version change outside of a semver range (if semver is used) or even at all, if a @branch, @tag or @commithash url is used.

[zaggino]

Anyway, we're slowly moving off submodules, it didn't freeze year ago. CodeMirror just moved to being an npm dependency recently (2 months ago?) and we're slowly moving others in various PRs. It's not a super fast process as we are also upgrading these and resolving problems the upgrades are causing.

[Pomax]

oh nice, I didn't know codemirror finally moved to npm! Yeah I understand it's a slow process (version tests are hard), it might be nice for tracking purposes to create an issue with - [ ] submodule-to-lift-up-to-npm entries so that they can be ticked off as they are moved, with date updates per entry so that people can see this is by no means a stalled issue?