We have an outline for a “Publishing Packages” article: https://github.com/meteor/guide/issues/45 but we decided to focus on other articles for the 1.3 release. Considering the 1.4 release is going to be focussed on moving towards npm and away from Atmosphere, I’m kind of doubtful we will end up getting round to writing it.
Community contributions are welcome though!
Is there a way to import within packages without explicitly depending on a package? I.e optional import? Example is here:
In Meteor 1.3 this blows up because Slack is undefined. If I try to add:
import {
Slack
} from 'meteor/acemtp:accounts-slack';
but that inevitably doesn’t work.
Only other way is explicitly depending on it but then that loads a bunch of packages that aren’t needed.
1 replyYes, you can use require
in this situation (http://guide.meteor.com/structure.html#using-require)
Got it. That makes sense. Still doesn’t work because now that package doesn’t export Slack
- good ol’ fun. I’ll try to coordinate with the package maintainers.
Hi @tmeasday My team wish to start the process of migrating our packages from Atmosphere to npm now.
How do we write npm packages that depend on Meteor apis?
Also I’m wondering if you see any need for a private npm repo like https://www.npmjs.com/package/sinopia
Thanks
1 replyI think you’ll need to wait for the core Meteor packages to
a) be rewritten to not rely on psuedo-globals (/the linker)
b) be imported into npm
There are a lot of little things to get right in doing so (let alone figuring out a system for doing so for non-core packages). We’re working on it but it’s still a little ways away.
Why do you think we’d need this?
1 replyOK…so a simple strategy like Where to publish? Atmosphere vs NPM won’t work?
I’m looking for a package sharing strategy. Since I posted that package I’ve learned more about npm link and local paths which I think negate the need for a local package repo.
2 repliesI guess that works, yeah. Kind of a pain but better than nothing in the interim, sure.
Yeah, I think we are just in that awkward limbo where we are quite on NPM and we are afraid to use the Meteor package system since we know it will die off this year.