Consider using npm deps instead of submodules

[cben]

package.js can point to arbitrary git urls.
Platforms like Heroku, OpenShift, Travis already run npm install on deploy.

• Mentally, 1 way to manage dependencies is easier than 2.
• For Heroku specifically, getting rid of submodules will unlock all kinds of features like auto-deploy, review apps (created for every PR), Heroku button, etc.
• Github Pages would no longer work. GH Pages do materialize submodules but not any build steps (OK, Jekyll but it can't fetch stuff).
• rawgit.com doesn't yet support submodules. But it doesn't support npm install either.
• Running locally would be about the same. npm install; npm start would be "one less tool", but "one more tool" for devs who have git but not Node and directly open file:/.../index.html. It's not obvious I'll be able to keep index.html on par with npm start anyway (cf. [semi] protect system pages (about, help) #101).
• Modifying a dependency during development is harder (npm link?).
• Byte-for-byte reproducible deps is harder, but I need to solve that anyway (freeze node & npm dep versions #82).

Crazier ideas:

• Run a fork of rawgit with whatever dep processing I want.
• "Build on http request" with tools like http://didact.us/beefy/, https://www.npmjs.com/package/d-proxy, or docpad? (This kills the idea of file:/.../index.html.)
• GH Pages can be "fixed" by any build tool auto-generating the gh-pages branch.
  • Perhaps even, node_modules or each node_modules/foo could be a submodule pointing to some auto-generated repo.
• Deps don't have to load at fixed path such as /CodeMirror/, they just have to load.
  • Fix GH Pages by Jekyll templating dependant on package.json? Nah, too specific even if possible.
  • Fix GH Pages AND Rawgit by client-side loader understanding package.json?! This can also win caching (Caching headers #74) and user-selected versions (Let user get any git version/fork at mathdown.net? #108) big time.

---

handy reference: https://github.com/wilmoore/frontend-packagers

[cben]

Fix GH Pages by Jekyll templating dependant on package.json?

Just for fun, doing

<script>
package = {% include package.json %};
...
</script>

is totally doable.
Plus something like (browserify'd?) https://www.npmjs.com/package/npm-package-arg ...

---

Future of npm for frontend: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

This doesn't mention the idea I might want some magic way to use package.json without running "npm install".
For that, the sanest idea is probably: build an npm-installing, caching (that's the hard part), rawgit clone.

[P.S. the "Deferred" label is here for a reason. As much as all this is tempting to experiment & bikeshed, it's an entirely separate project from Mathdown.]

[cben]

For Heroku, it's probably possible to support submodules with all flows via a buildpack.
cf. https://github.com/mietek/heroku-buildpack-submodule-example
and https://github.com/peterkeen/heroku-buildpack-vendorbinaries

[cben]

I've tried installing mathjax via npm
[6eff9f6, f7e0618]
in hope it'll make rhcloud installs faster (#115). It made them slower :-(

I'm closing this as currently I don't plan to switch submodules to npm. Will re-open if I reconsider.