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.