Any consensus over conventions on meteor-signals on npm?

packages
1

Now that we are getting even closer to embracing npm, I’m having this growing gut feeling that it will become harder to spot quality meteor"-related" packages on npm.

Although it still has its own problems, atmosphere has one huge benefit that it is a place to find meteor packages.

How do we do that on npm? What would be some of the more important searchable attributes of a package on npm that signal its relevance to meteor?

What do we make sure we do when we publish a package on npm so that the meteor community gets to know that it exists?

My daily working habit includes checking the recent packages on atmosphere to keep tabs on the latest cool stuff as well as updates. How do we do that on npm (for meteor)?

2 Likes
2

Convention seems to be to prefix package names, so meteor-some-package, and then use meteor in the keywords.

3

Well, an npm-noob search for meteor brings up just a handful hits which reveals https://www.npmjs.com/package/meteor as the best result. That does not quite strike me as meteor-friendly.

Furthermore, the keyword search results https://www.npmjs.com/search?q=meteor seem to have no particularly helpful order.

I know it is yet too early to conculde that, but I’m afraid, the situation may not improve as npm becomes more mainstream for meteor apps/packages.

I think some kind of convention and an npm meteor package aggregator equivalent to atmosphere that takes that convention as its main signal might go a long way.

1 Like
4

Yes, I mean general npm convention, rather than what is currently followed for meteor related packages. But I agree the npm search / sort order is not the most helpful.

However there is the possibility for Atmosphere or another site to list meteor specific NPMs, similar to https://react.parts

5

Hm, do you know how react.parts aggregates react packages, how accurate
it is and if there are any false positives?

I’d say a meteor counterpart to that would be really helpful.

6

it’s based on having “react-component” in the keywords so false positives are non-existent, and since there are several search sites that use the same keyword, any react component worth knowing about uses it, so false negatives are also low.

7

Great! I hope that kind of convention gets mainstream for meteor as well.

1 Like
8

I think this is something we should actively promote somewhere around 1.3 release. What’s a good keyword? Just “meteor”?

3 Likes
9

meteor-platform?

(I’m making the assumption that a double-barrelled keyword is better for reducing false positives/negatives).

3 Likes
10

@sashko I agree with @robfallows’ “meteor-platform” suggestion.

There already are unrelated packages that use the meteor keyword. I’m also happy that you agree on promoting something like this.

Perhaps if core meteor packages were to be published on npm, they would lead the way by example.

2 Likes
11

meteor-platform looks good and will filter out non-related stuff from NPM. Also, in Meteor they’re called packages - what’s the word on NPM? Modules? Libraries? Nodes?

12

when browsing react.parts I was missing categories.

a base keyword like meteor is good, but it could be useful if we use some sort of name spacing convention with categories.

in perl, modules were more easily found on cpan, maybe we can take categories into account?

13

Maybe NPM packages could also be listed in Atmosphere if they’re relevant to Meteor.

2 Likes
14

The whole npm registry seems to lack the notion of categories, so I guess trying to get something going specifically for meteor may not be very intuitive.

Furthermore, Meteor’s alignment with the broader javascript ecosystem makes the distinctions more blurry where a meteor related package may serve a larger javascript ecosystem while a completely unrelated package may very well be valid for a meteor app. Then of course there are the meteor-only packages which I believe will in time come to be a very small fraction.

15

one approach could be that meteor by convention recommends usage of certain keywords, in addition to meteor, and then for the crawler, it can categorise by using meteor and the additional key words / tags.

1 Like
16

Yeah I think it would be super awesome if the next version of Atmosphere also indexed NPM packages with a certain keyword. Regarding categories, does anyone know of a package system existing today that does this? It would be nice to follow a successful example.

I think meteor-platform could be a fine keyword.

@avital @benjamn I think this is a pretty simple but high leverage thing we could do, can we write this somewhere in 1.3 release plans?

2 Likes
17

There’s some valuable insight at https://unpm.nodesource.com/ revealing some patterns and data that may be signals to package quality.

It seems prefixing is the foremost accepted pattern to create a pseudo-community.

If we can also raise some awareness around using proper

  • keywords
  • readme
  • github link
  • license
  • tests
  • perhaps a “made for meteor” badge?

as well as a search-engine-friendly aggregator (atmoshpere) and cross referenes here and there, we can use the whole thing to our advantage.

Npm seems to have around 150 thousand packages published and it seems just about 10% got it right in terms of “quality”.

Since we are just starting off, we can make use of those lessons learned.

2 Likes
18

So are you saying it would be better to have all of the packages called meteor-* rather than having a package.json keyword?

19

Perhaps http://react-components.com/ could serve as inspiration. It’s really a convenient wrapper for searching a subset of what’s listed on https://www.npmjs.com/.

The majority of the packages listed are prefixed react-*, but not all. Packages not prefixed with react do have keywords react, react-component, react element, etc. So you could use a combination of the two approaches.

20

Are you asking for a new Atmosphere feature? What’s the argument in favor of coupling that with the 1.3 release?