Now available on bower and npm as "traits.js"

[Michael Bradley, Jr.]

After being introduced to traits.js about a month ago and realizing I had a use case, I finally sat down this weekend to learn the library and begin my work with it.

To make life easier, I wanted the library to be available on bower, in addition to npm. So, I decided to create a fork on GitHub; but more than that, I retooled it with respect to npm "scripts", a mocha/chai test suite, and so on (made for a good way to learn also):

    https://github.com/michaelsbradleyjr/traits.js

    $ npm install traits.js

    -- and/or --

    $ bower install traits.js

The initial git tag and corresponding releases on bower and npm match up exactly with the 0.4 release of the original, with one difference which I will explain below.  In future releases, I may alter and add to the API, and I do plan on dropping the integrated ES5 shims in favor of using a library-dependency for that purpose. But my 0.4.0 release will always be a match for the original.

The only thing that's different is that the `Trait` constructor lives on the exported object (as may other facilities in future releases). So you would do something like:

    var Trait = require("traits.js").Trait; // Node.js

    -- or --

    Trait = traits.Trait // browser global scope

I hope other JS devs will find this useful, and I want to thank Tom for his excellent work on this gem of a library. I've tried to give ample credit and pointers to the original library/author. I don't wish to give anyone the impression I'm claiming the library as my own work.

One final note:  the "browser reporter" for mocha is a bit on the slow side -- it can take anywhere from 10x - 50x as long to run the tests in a browser as compared to qunit. We're still talking fractions of a second in Chrome to two seconds on an iPad, but I thought some folks might notice so I wanted to give a heads up. Note that it's the "browser reporter" that's slow -- the library itself hasn't suffered any inherent slowdowns by way of my fork/retooling, and the tests run super fast under Node.js.

Best regards.

--

Michael Bradley, Jr.

@michaelsbradley

[Tom Van Cutsem]

Hello Michael,

Thanks for the heads-up! I can only encourage people forking my library and modifying it to suit their own purposes.

Note that for npm, there already exists a package for traits.js (called simply "traits", <https://npmjs.org/package/traits>), packaged by Nathan Stott. I hope this won't confuse users (currently there's little possibility of confusion as both probably contain the same traits.js 0.4 release :-)

Thanks for putting traits.js up on bower.

That said, if you encounter any bugs or fixes that would benefit the original traits.js library, I'd be happy to incorporate them.

Regards,

Tom

2013/9/3 Michael Bradley, Jr. <michaels...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "traits.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to traits-js+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Bradley, Jr.]

Thanks, Tom.

I will mod the README and add a super brief "compatibility" section, right near the top, that says something to the effect of "for 1-to-1 compatibility with the original traits.js, please use the v0.4.0 release".

I saw that "traits" was already on npm; however, there is basically no node/npm tooling in the github repo to which it corresponds. I could have forked from that and issued a pull request -- I waffled back and forth on that and then decided to go this other route.

I figured that since the 0.4.0 release would always be essentially the original traits.js (i.e. except for the exports mechanic), that it wasn't false advertising to name it exactly after the original. If confusion seems to arise down the road, I will be happy to consider renaming the repository and published packages.

One thing I forgot to mention yesterday (though it's noted in the README) is that I packaged traits.js in such a way that it can be used with an AMD loader like RequireJS, in addition to being loadable with a <script> tag or with Node.js's "require" function.

--

Michael Bradley, Jr.

@michaelsbradley

[Nathan Stott]

It would have been way better for you to have forked it and issued a pull request. I could have even given you publish rights to the npm repo.

[Michael Bradley, Jr.]

Nathan, perhaps you're right -- I could have inquired via this mailing list or a github issue before plunging ahead.  Apologies for my zeal.

A few points:  this is the world of software, and the steps taken are not un-doable. Also, my intentions were not that of a land grab. So, if you and Tom feel it would be better, I could:

Fork from Nathan's "traits" on github and catch it up with my work on a feature branch. If it's acceptable, then I can issue / merge (if I have rights) a pull request, tag a 0.4.1 release and publish to npm and bower, now as "traits". At that point, I could delete my "traits.js" repo and un-publish it from npm and bower.

There would still be the issue of my independently evolving the library. I could do that on my own fork of "traits" of course, and never land them in Nathan's repo, but then I would need a different name than "traits" if I want to publish on npm/bower, in which case I suppose it's fair to ask if I should be doing that under the name "traits.js" -- perhaps "traits-ng" or something else would be better.

Thoughts?

[Nathan Stott]

I'm not trying to chastise you, I am super happy that someone is enthused about traits. I would just have been happy to turn over the npm repo to you so that we don't have two :). We can proceed however you would like as right now you have more zeal than I do, honestly.

[Tom Van Cutsem]

Given that Michael wants to do his own thing with the library, perhaps it's not that bad to have 2 independent npm packages. Nathan's package can remain in-sync with all existing documentation. Michael can then continue his work in his package without interference and without any additional hassles.

The compatibility note in your README is much appreciated.

Cheers,

Tom

2013/9/4 Nathan Stott <nrs...@gmail.com>

[Michael Bradley, Jr.]

Okay, Tom, that sounds reasonable to me.  :-)

I have updated my fork's README to include the proposed "compatibility" section. 

See:  https://github.com/michaelsbradleyjr/traits.js

Best regards.

--

Michael Bradley, Jr.

@michaelsbradley

On Friday, September 6, 2013 10:05:45 AM UTC-5, Tom Van Cutsem wrote:

Given that Michael wants to do his own thing with the library, perhaps it's not that bad to have 2 independent npm packages. Nathan's package can remain in-sync with all existing documentation. Michael can then continue his work in his package without interference and without any additional hassles.

The compatibility note in your README is much appreciated.

Cheers,

Tom

2013/9/4 Nathan Stott <nrs...@gmail.com>

I'm not trying to chastise you, I am super happy that someone is enthused about traits. I would just have been happy to turn over the npm repo to you so that we don't have two :). We can proceed however you would like as right now you have more zeal than I do, honestly.

On Wed, Sep 4, 2013 at 10:05 AM, Michael Bradley, Jr. <michaels...@gmail.com> wrote:

Nathan, perhaps you're right -- I could have inquired via this mailing list or a github issue before plunging ahead.  Apologies for my zeal.

A few points:  this is the world of software, and the steps taken are not un-doable. Also, my intentions were not that of a land grab. So, if you and Tom feel it would be better, I could:

<snip>