Maybe NPM packages could also be listed in Atmosphere if they’re relevant to Meteor.
2 Likes
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.
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
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
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
So are you saying it would be better to have all of the packages called meteor-* rather than having a package.json keyword?
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.
Are you asking for a new Atmosphere feature? What’s the argument in favor of coupling that with the 1.3 release?
No I’m asking for Meteor NPM support to come with a recommendation of tagging your Meteor-specific NPM packages so that we can find them later.
What do you mean by “Meteor-specific NPM packages”? What’s an example?
(That is – NPM packages can’t access Meteor globals, etc. So I don’t really know what you’re talking about)
For example, simple-schema could be published to NPM, and it would be helpful for people for it to be tagged so that they know it works well with Meteor.
But could it? I see that it references the Match global that can’t be used outside of Meteor.
Both, actually; where a prefix would be more favorable if the package is more meteor specific than it is generic.
Afterall, packages could be meteor specific or meteor related where a prefix would signal the specifity whereas the keyword would signal the relation.
I see that it references the Match global that can’t be used outside of Meteor.
AFAIK that is soon to be changed.
There also seems to be a tendency to publish directly on npm as soon as 1.3 gets released.
Here’s the thing: There are a bunch of reasons why publishing Meteor packages on NPM to be used within Meteor via npm install is a bad idea:
- Dependencies on packages like
underscorewill lead to multiple instance of that package in the client bundle (this will remain until Meteor adopts NPMv3 as the top-level package manager) - Any dependencies on Meteor packages such as
trackerorrandomwon’t work - Any package with assets such as templates or
.cssfiles won’t work - Any dependency on Meteor build plugins would have to be replaced by the parallel version in NPM (which isn’t always clear how to achieve)
So I don’t actually see a future where 1.3 lets Meteor developers comfortably publish their packages on NPM… Meteor 1.4 or whatever comes next though – yes, that should definitely be a goal
Am I missing something?
4 Likes
an approach for tagging, labelling, meteor packages on npm, could also be to do it in a decoupled fashion on the site that shows the output of the npm matching in the meteor keyword, then people using the meteor index can categorise on the go.
pros
- gives more flexibility to making some good index browsing and referencing tools
cons
- it is not all integrated in npm (but maybe it is ok here, because it is an extra layer of organisation that is maybe not desired for npm?)
another perhaps complementary approach is to have categories specified in the package.json file which are used to help categorising on the meteor index site. the categories section in the package.json which can be nested, can then be read for the packages the crawler picks up using the meteor-platform keyword match. also available to any other indexers including external to meteor choose to adopt the categories approach, if desired.
examples of package systems with categories ‘in use’ today:
- freebsd ports: http://www.freshports.org/categories.php
- perl modules: http://www.cpan.org/modules/by-category/ (have seen better representations
)
Nope, you are not missing anything, but the thing is, as soon as Meteor made React a first class citizen, also getting in cosmos:browserify, npm kind of become more relevant than it ever was.
And the latest addtion of imports with 1.3 got everyone even more curious.
Existence of webpack and meteorhacks:npm just happened to be the icing on the cake.
The current state is, most prominent bloggers produce meteor literature around a world where npm is the defacto meteor package repository and atmosphere is kind of dead and irrelevant.
I am not saying it is yet true, but it seems to be where the community is heading towards, unless MDG comes up with a radically different and better approach to app modularity and ecosystem integration.
Perpahs meteor developers need more coaching with this. Perhaps the official guide can have a section on what’s next and how to be best prepared for the not so distant future.
in 1.3 I was kind of expecting that there would be no globals, and if a NPM module would need to, it would be able to import Meteor or eg. Tracker from meteor/tracker, or Match from meteor/match. Or at least it would be possible to configure it to be so.
This is something we’re aiming for but is not in the decks for 1.3
I think Meteor will get quite a bit more buy-in from the greater JS community once it reaches that point. It’s something MDG should consider giving high priority, with the acknowledgment that it won’t be 100% there for Meteor 1.3.