I tried “node init” but it only created a package.json file for me.
I heard @arunoda had a good template for an ES2015 NPM package with testing lying around.
You can use this: https://github.com/kadirahq/npm-base
This is what @sashko has mentioned.
Looks pretty good, Arunoda. Thanks for putting that together. Definitely going to bookmark that one.
Do you have the same thing with a template for server/client code?
We have ~100 packages we’re getting ready to implement for the HL7 FHIR resource list; and they’re all pretty standard… they require the
meteor-platform and define a schema, collection, publication, subscription, and some basic CRUC components. I’d like to implement them in such a way that they’re forward-compatible with NPM.
Do we just drop the
package.js file in there? Where do
/server directories go?
@awatson1978 this is for a NPM library and never meant to put any client side or other stuff.
Ah. There has been talk about moving Atmosphere packages to NPM. Thought you had maybe figured a pattern out for that. Okay. Thanks!
Yeah we are thinking about this problem internally as well - it’s clear that Atmosphere packages currently have a lot more built-in features and function much better as units of app functionality. But right now NPM is a great place to publish something that is essentially just a single function or class, with minimal dependencies on the environment.
About the atmosphere to NPM switch.
We tried this too and it works upto some extent.
Once example is react-komposer. It uses Tracker and published to NPM.
I’m trying to FlowRouter’s SSR API in react-mounter.
This is just about using the global variables. We can something better. This is how I think about it.
- Publish a NPM package called
meteor-core which let us access whole Meteor core API and get access to packages. It should also support stuff like
- Meteor should support getting multiple source files for different architectures via some
Until above these things are getting completed, I don’t think it’s 100% safe to use NPM as a Atmosphere replacement.
But for libraries, NPM should be the way to go.
Yep. We definitely do not intend for people to replace all of their atmosphere packages with NPM in Meteor 1.3 - it was not designed that way. It makes sense for React specifically so that we don’t have to publish wrapper packages.
Anyway, I started doing the below (seemingly excellent) Redux tutorial last night and was struck by what a bewildering mess of steps it was just to add the half dozen dependencies needed for the tutorial. Maybe the steps themselves weren’t so bad but, when I made a mistake in one of them, it was far from obvious what the problem was or how to fix it. http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html
I hope that in eventually moving to NPM, Meteor doesn’t lose it’s “stupidly easy to create a project and get coding” feature that got me hooked at the start.
npm-base doesn’t work for me. can I please get another recommendation?
You should probably consider @benjamn’s jsnext npm skeleton https://github.com/benjamn/jsnext-skeleton
He gave a pretty good talk at empire node related to it. http://youtu.be/-zch_YmKfa0 (About 30 min in about jsnext)
Since it’s his baby at MDG, I guess jsnext is officially supported. We follow the skeleton.
PS: That topic came up already here Meteor 1.3 here and now it's time to think about NPM
Thanks mate. That worked out of the box. I’m gonna watch that video as well now.