Package rating and reviews

[JohnDotAwesome]

NPM has exploded with packages often bearing very similar names and replicating functionality (like async and asyncjs). It'd be really nice if there were comments and ratings on modules to help decide which module to pick during development. Sure you could google around, but it seems like a pretty useful thing to have an a package repo.

Would anyone else like to see this in Jam?

[Caolan McMahon]

> It'd be really nice if there were comments and ratings on modules to help
> decide which module to pick during development.

I agree, I've been thinking of adding comments to package details pages
and a 'star' feature to gauge relative popularity (and potentially
provide you with notifications when a pacakge you care about has an
upgrade available). You should already see GitHub watcher/star-gazer
counts in package search results and category listings (if the package
has a github property set), which will hopefully help people gauge
popularity too.

Of course, there are lots of exciting things to work on with regard to
Jam at the moment, so your feedback on which features are important will
help me to prioritize.

Caolan

[Jarrod Overson]

The naming issue was a big problem in cpan (the perl packaging solution), where naming and namespaces became more of a frustration than a benefit due to the limited options over time. It also unfairly values early libraries that were able to acquire a common name.

One of the proposed solutions that got the most traction was including the publishing entity in the namespace allowing for things like jquery to be installed via jquery/jquery while a forked version would be installable via (something like) jsoverson/jquery

I (with all of my open source heart) hate unique names being used for packaging because you get problems like the one mentioned (async vs asyncjs) and this is already a problem with npm.

With github being so central to many JS projects nowadays using the github entity as a namespace would probably be very doable.

My 2 cents.

--

Jarrod Overson

--
You received this message because you are subscribed to the Google Groups "jamjs" group.
To post to this group, send an email to ja...@googlegroups.com.
To unsubscribe from this group, send email to jamjs+un...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Caolan McMahon]

> The naming issue was a big problem in cpan (the perl packaging solution),
> where naming and namespaces became more of a frustration than a benefit due
> to the limited options over time. It also unfairly values early libraries
> that were able to acquire a common name.
>
> One of the proposed solutions that got the most traction was including the
> publishing entity in the namespace allowing for things like jquery to be
> installed via jquery/jquery while a forked version would be installable via
> (something like) jsoverson/jquery
>
> I (with all of my open source heart) hate unique names being used for
> packaging because you get problems like the one mentioned (async vs
> asyncjs) and this is already a problem with npm.
>
> With github being so central to many JS projects nowadays using the github
> entity as a namespace would probably be very doable.

"Publisher/name" ids were considered, but it makes package dependencies
more difficult to reason about. This would be fine in a server-side solution
(like Node.js) where installing multiple versions of a package could be
handled nicely. When pushing code to the browser we obviously need to
ensure we only have one version of each library if at all possible.

The approach I'd like to take is a 'provides' property on new packages.
Then you could see the unique id more like an interface that packages
adhere to. That way you could install mycustom-jquery and when other packages
require 'jquery' they'll get your forked version (which should obviously
provide a compatible API). This has not been implemented yet, but might be a
good way for us to handle the likes of lo-dash and zepto etc.

There are certainly some advantages to further namespacing of packages, but
at just over 100 packages in the repository I think it will be a while before
unique names are a significant problem. Until then, it's very convenient
to be able to do "jam install jquery" and get something sensible.

As for using GitHub accounts for namespacing, if we were to go down
the namespaced route it would probably be sensible. Just don't expect
me to agree lightly to using a proprietary server as an essential core
to an open-source project ;)

I'm interested to hear other people's thoughts on this...

-Caolan

[JohnDotAwesome]

I really like the provides style. Maybe the provides can be namespaces too. So if your package provides jquery, you do jquery/myquery. This makes it pretty clear that the myquery package seeks to provide the same functionality as jquery. 

Not a huge fan of using github account names as namespaces. The names have no semantic meaning and not everyone uses github. Plus, I don't like relying on a company that isn't necessarily directly involved in the development of the project.