add support for twitter bower

[agrberg]

the build script copies the built version of sinon to the root of the repository and includes this file

[cjohansen]

Is there a way we can have bower use what's in pkg instead? Also, how does bower use this file? From master?

[agrberg]

Bower can use what is in pkg but that would require pkg being removed from .gitignore and included in the repository.

Bower's typical behavior is to clone the repository to a specified directory on the user's machine. It also uses tags to determine the version of the repo. I don't believe there is a rule about where the built JavaScript file should live. It's almost always in the root and the one library I use where it is not, Marionette, it is found in lib.

[cjohansen]

I'm not overly keen on keeping generated artefacts in the source repo. Especially not if it allows people to depend on arbitrary versions from git. Is there some way we can ship builds to bower when we do our regular releases?

[smistry-toushay]

bower supports installing from a URL that points to a zip or tar file. Would that be a better option?

[cjohansen]

So it can use the npm tar then I guess? Since recently it even includes a built file.

[smistry-toushay]

Yes, but you have to run

bower install <tar URL>

Is there a URL I can try out?

[cjohansen]

I currently don't have a working node install. Do npm install sinon and it will print the URL to the tar file.

[smistry-toushay]

Just tried:

bower install https://registry.npmjs.org/sinon/-/sinon-1.6.0.tgz

Two issues:

• install into components/sinon-1.6.0 preferred folder would be components/sinon
• bower only untars it, so components/sinon-1.6.0 contains components.json and index.tgz

[cjohansen]

I decided I don't want bower-specific code or generated artefacts in the source repository. If there's a way to produce something bower-consumable from the build script when we do releases I would be willing to accept a PR for that.

[agrberg]

Some CI servers have problems with zips and tars.

Bower would look for the latest tag, v1.6.0 in this case, if one were to run bower install sinon.
Alternatively you can run bower install git://github.com/cjohansen/Sinon.JS.git with an optional # and version. This requires only tagged commits to contain the generated library.

In your component.json file you can specify the name of the library and either a version to get the data from bower, or the same structured git url as in the previous example.

Anyway, if it's a problem or if you don't want the built code hanging around, I can look for other solutions.

[cjohansen]

As far as I understand component.json is used by two different projects, and they don't use compatible versions. Thus I don't want that flie in the repo. I also don't want to have generated code in the repo. If there's anything that can be done at build-time, I'll be happy to help.

[agrberg]

Thanks @cjohansen. For right now I'll just do what I need on my fork and maybe see if Bower has any steps to build or operate on a repo after cloning it. I'll post back if it does.

What other project uses component.json? I may have been unclear earlier, Bower doesn't require the library to have component.json, it just allows you to use one in your project to define your dependencies so you can install them all with a simple bower install.

[mantoni]

This project does also use component.json: https://github.com/component/component

[glyuck]

I just write in my component.json:

"sinon": "http://sinonjs.org/releases/sinon-1.6.0.js"

And after bower install i have sinon.js saved to components/sinon/index.js

[mantoni]

You could create a sinon-component project with sinon as a sub module and maintain it there.

[agrberg]

@glyuck Do you do that manually or is there an after install hook for bower?

@mantoni Can you elaborate on your solution?

[mantoni]

Just a thought since request for component and others are coming quite often now:

If anyone is willing to support component, it might be a solution to create a git repository with Sinon.JS as a sub module (see http://git-scm.com/book/en/Git-Tools-Submodules). GitHub supports sub modules.

This would allow you to pull in whatever release version you like, run the Sinon build and, if required, additional build steps. This wouldn't require you to add anything to the Sinon repository itself.

[smistry-toushay]

You might want to look at this https://github.com/components

I think those component shims are maintained manually.

[agrberg]

Ah I see what you're saying. Basically sort of making my stopgap solution (including the result of build in my fork) somewhat official with the Bower folks. I'll message them and see how they prefer to handle this.

[svnlto]

@LtCmdDudefellah @cjohansen bower now has renamed component.json to bower.json

@cjohansen would you be willing to reconsider this issue and maybe ship a distdirectory that contains the built version of sinon? The future version of the bower-registry (which I am currently working on) will support archive uploads btw.

[cjohansen]

@svnlto where do you want the dist directory? Can you use http://sinonjs.org/download/?

[svnlto]

@cjohansen if you commit the pkgdirectory that is produced by your ruby build script then the following bower.json file should be all you need to add to make this work, i.e. solve this issue.

{
  "name": "sinon",
  "version": "1.7.3",
  "main": "pkg/sinon.js",
  "ignore": [
    "**/.*",
    "lib",
    "test",
    "build",
    "jsl.conf",
    "node_modules",
    "release.sh"
  ]
}

[cjohansen]

I still don't want to commit generated files, as explained before. My policy for these things stays the same: If there's anything in Sinon source that keeps people from using it in a given context, I welcome patches. We recently changed our CommonJS detection code for the Component people. Additional meta information should be maintained by someone passionate about the package manager in question.

I think it will be easier for any new package manager if it supports packages as an entity separate from the source code.

[svnlto]

Fair enough, will create a fork and register it with the registry.

[slashdotdash]

bower install --save-dev sinon=http://sinonjs.org/releases/sinon-1.7.3.js

[mikeobrien]

👍 on bower support. A few projects have gone this route to enable support for package managers like bower but not have built artifacts in their repos. There is even a grunt task to automate it. Maybe that would be a reasonable middle ground?

[cjohansen]

If you want to maintain a bower package for Sinon, feel free to do so. I don't intend to.

[mikeobrien]

Thats just it, this solution doesn't require you as an author to maintain any packages. But it allows package managers to interface with your project. So its a win-win solution. Basically all you do is push a built version of sinon to a repo here, thats it. Then people can wire up whatever package manager they want to pull from there.

[fabiosantoscode]

@cjohansen

If you want to maintain a bower package for Sinon, feel free to do so. I don't intend to.

Don't mind if I do. This is an awesome library and I really don't want to distribute it black-boxed as a third party script in my repo.

I'm going to create a fork, and a bower package sinonjs-built containing a build of sinon for every tag.

[fabiosantoscode]

Package created. You can now bower install sinonjs-built.

[agrberg]

👍

[nubz]

👍 bower install --save-dev sinonjs-built

[kmhigashioka]

👍