include jspm package configuration

[guybedford]

With this configuration in the package.json, Bootstrap can be included in a page through jspm with:

http://jsbin.com/osIYuDOJ/1/edit

This includes minification with source maps, shimming the jquery dependency, setting the main entry point and loading resources from the "dist" folder.

For example, this approach is used by http://getkickstrap.com/, a Bootstrap framework.

Bootstrap itself isn't downloaded as a clone of the Github repo, rather the Github release is detected and used instead.

Questions welcome, I know package.json littering can be a contentious issue. There are other options as well so happy to discuss this.

[cvrebert]

LGTM.
/cc @fat @mdo

[mdo]

What's the usage around jspm? Never heard of it.

[guybedford]

@mdo if you're worried about the "jspm" prefix, the same configuration also works at the base level of the package.json. As much as possible it extends existing properties like "directories". The only new properties are "shim" and "buildConfig" in this case. Let me know if you want to go this route.

We're in early adoption - I completely understand if you only want to support something completely established, it just makes it much easier to maintain having this information in the package itself instead of needing the override service.

[mdo]

The actual code isn't really of concern to me, only that we're not getting ahead of ourselves in supporting something new and not screwing up anything for the rest of the package.json.

[cvrebert]

npm install gives no warnings or errors with the modified package.json.

[guybedford]

package.json was designed in CommonJS to be extended, and NPM encourages it if anything (see the comment after the third quote in this article - http://blog.izs.me/post/27987129912/tj-holowaychuk-components). I personally don't believe in having multiple package metadata configuration files (this being a different concept from build files), but I know this can be personal preference.

I suppose the question is more whether Bootstrap wants to be seen to be supporting a new technology. That's why I suggested the non-jspm prefixed base-level configuration of:

package.json:

{
    "main": "js/bootstrap"
  , "directories": { "lib": "dist" }
  , "shim": {
      "js/bootstrap": {
           "imports": "jquery"
         , "exports": "$"
       }
  }
  , "buildConfig": { "uglify": true }
}

in case this is the real issue here.

In this case consider that jspm has specified the shim and buildConfig package.json properties for use, in a way that could even be shared with other package managers if they cared to use the same configuration.

[adamjgrant]

With the code you have above, it would make sense that any such technology that loads Bootstrap as a singular package could use the configuration--it wouldn't be specific to JSPM.

[mdo]

👍

[guybedford]

Amazing, thanks!