Publish to npm instead of atmosphere about redis-oplog HOT 9 CLOSED

Here it is: https://github.com/maxnowack/meteor-npm-package
It uses this small package to get globals from meteor: https://github.com/maxnowack/meteor-globals

I think the easiest way to depend on a meteor package would be, to check if the package is there and otherwise log a message, throw an exception and kill the process. What do you think?

from redis-oplog.

Just a note that merely moving to npm doesn't automatically mean support for 1.2.x. It would also depend on not using any of the Meteor core or packages APIs that are not available in 1.2.x. That would be difficult to control since versions of Meteor packages cannot be controlled through NPM. We might have to rely on unit tests. But I'd worry about it only after the move to npm is complete.

@maxnowack nice initiative with meteor-globals!

For unit testing, there already seems to be supporting packages like https://github.com/Astrocoders/meteor-mocks and https://github.com/meteor-velocity/meteor-stubs. I haven't used them personally though.

from redis-oplog.

Do you have an example of an npm package that is specifically built with Meteor + also has tests built-in ?

from redis-oplog.

I'll build one ;)

from redis-oplog.

how would we tackle package dependencies ? I believe that's the main issue.

from redis-oplog.

actually we only depend on : dburles:mongo-collection-instances really, and I use it just to get the collection by a name, I believe that can be solved.

from redis-oplog.

Amazing. It's really good, so the only advantage for moving to npm is to offer support for 1.2.x ?

from redis-oplog.

mainly yes, but it also feels like atmosphere is deprecated.

from redis-oplog.

Since this project is meteor related and does not work with the whole ecosystem, until Atmosphere is deprecated it makes no sense to put it to npm. It will lead to unecessary overhead.

from redis-oplog.