Publish to npm

[gideonthomas]

We should publish and version bramble in npm (and git) so that users can just npm install it directly into their projects.

[humphd]

Is there a model for this we can follow? Specifically, the fact that this is a module that requires a webserver to host it.

I think it would be cool to do this. I notice that code.org does it: https://www.npmjs.com/package/@code-dot-org/bramble

cc @Pomax, @cadecairos

[Pomax]

technically we don't even need to publish to NPM's registry, we just need to point to our location in the package.json dependencies. We can just make thimble require "bramble": "https://github.com/mozilla/brackets@master" and that should work. As a mozilla repo it's going to be around for as long as Thimble itself is, so no risk of "personal forks" disappearing.

[humphd]

However, there are build steps required, which would still need to get run for that to be useful. How does one overcome that without checking in build artifacts in the tree?

[Pomax]

you can make that an npm postinstall in specifically our brackets' package.json to make the build run as part of the general install process though.

[humphd]

That's an interesting thought. What about the runtime aspect? You wouldn't start an http-server in a postinstall step. How would you deal with that runtime dep?

[Pomax]

You wouldn't, you'd make brackets start up as part of starting up thimble. so here you'd have a "postinstall": "npm run build", and then in Thimble you have:

"start": "run-p start:brackets start:thimble",
"start:brackets": "cd node_modules/brackets && npm start",
"start:thimble": "node scripts/start.js",

(with run-p being the shorthand cli utility for npm-run-all --parallel that comes along with run-s when you install npm-run-all)

[humphd]

Excellent, we're getting somewhere. Some further thoughts:

• If we did this, we'd need to adhere to semver for our dist/bramble.js API, which would be good
• What is the right way to allow someone to use the npm'ed version vs. a version in their tree? env var?

[Pomax]

• semvers are excellent for APIs
• hmm, pretty sure npm link gets to override whatever is in ./node_modules/, so someone would set an npm link in their not-part-of-thimble bramble dir, and then in the thimble dir they would say npm link bramble and that should be sufficient.

[humphd]

I think we should move forward with this. I'm specifically concerned about version skew between what Thimble needs (i.e., what is available on the Bramble iframe API, basically which version it is) vs. what Brackets is currently running (i.e., dist/bramble.js). If Thimble loaded bramble.js via npm and versioned it, we wouldn't blow up because some method is missing in the API.

This pattern is something we've done before, for example, with the make-api (server) and make-api-client lib. I wonder if we learned any lessons from that approach that we could improve on here (cc'ing @cadecairos and @simonwex). Basically, what we're going to end-up with is:

• Thimble server, hosts Brackets iframe via Bramble API module included from npm.
• Bramble API module, versioned on npm. This provides the bramble.js API, which injects and manages the iframe for the editor.
• Brackets hosted on S3 and https://mozillathimblelivepreview.net/..., which is what gets loaded in the iframe.

To this point, we haven't done anything about versioning. We just push master to S3 and that's what's available. However, as I push ever further toward pure-offline support with Service Workers, I'm nervous about version skew in the cached Thimble or Brackets code the user loads. For example, they might have a newer version of Thimble loaded which includes some new API, but the code that implements it in Brackets isn't loaded yet (still downloading to SW cache).

A lot of people seem to deal with this problem by having versioned URLs of one form or another. Should we add a version to the URL we push to S3? Instead of just loading https://mozillalivepreview.net/production/dist/, maybe we should do https://mozillalivepreview.net/production/dist/version/ ?

I'm raising this now because pretty soon I want to start doing the rest of the patches necessary for offline and service workers, and having this solved will eliminate or reduce issues we have to solve when we get there.

[Pomax]

hm, we could start with "not publishing to npm" but making sure we version things in git, so we can do npm install mozilla/brackets@b12345 - as long as we don't use the same version pattern that the official brackets does, that shouldn't conflict. It does mean "pegging" brackets to a specific version but that doesn't feel like as big of a problem.