Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish to npm instead of atmosphere #52

Closed
maxnowack opened this issue Nov 23, 2016 · 9 comments
Closed

Publish to npm instead of atmosphere #52

maxnowack opened this issue Nov 23, 2016 · 9 comments
Labels

Comments

@maxnowack
Copy link
Contributor

maxnowack commented Nov 23, 2016

This would probably resolve #35
We could rely on meteor globals with this pattern:

function getMeteorGlobal(packageName, globalName) {
  if (!global.Package || !global.Package[packageName]) return
  return global.Package[packageName][globalName]
}

const Mongo = getMeteorGlobal('mongo', 'Mongo') // from core package
const RedisOplog = getMeteorGlobal('cultofcoders:redis-oplog', 'RedisOplog') // from atmosphere package
@theodorDiaconu
Copy link
Contributor

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

@maxnowack
Copy link
Contributor Author

I'll build one ;)

@theodorDiaconu
Copy link
Contributor

theodorDiaconu commented Nov 24, 2016

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

@theodorDiaconu
Copy link
Contributor

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.

@maxnowack
Copy link
Contributor Author

maxnowack commented Nov 24, 2016

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?

@theodorDiaconu
Copy link
Contributor

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

@maxnowack
Copy link
Contributor Author

maxnowack commented Nov 24, 2016

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

@gaurav-
Copy link

gaurav- commented Nov 24, 2016

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.

@theodorDiaconu
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants