I want to create a library of JavaScript functions (doing math stuff) for Meteor, Node and w/e else, compatible with ES6 and Meteor 1.3. Which is the best skeleton to start upon? I don’t want to write the boilerplate code. I’ll make it open source on GitHub. I want to be able to add testing easily, even though I haven’t done this before.
I tried “node init” but it only created a package.json file for me.
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 /client, /lib, and /server directories go?
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.
meteor-core which let us access whole Meteor core API and get access to packages. It should also support stuff like Meteor.startup.package.json configurations.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.
Sorry if this is off topic, but my entry point into JavaScript and web development was Meteor and todate I’ve mostly only used npm packages thorough Meteor (via meteorhacks:npm).
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.