I have standard node.js REST API. And I want to use some meteor's packages like Minimongo, Tracker, Blaze (any Meteor's package)
There a lot of articles how use npm modules in Meteor but I have opposite task. Should I create some wrapper to make it possible to use as a Node modules?
There is similar question: How to use Meteor packages outside of Meteor?
but nobody answer.
this is a good question, but you cannot just use require for a meteor in npm. You also cannot use Drupal modules in in plain PHP, it will not work as in the context they are written for. Yes you can use npm packages in Meteor, but only because Meteor is build on top of Node, not vice-versa.
Meteor has its own packaging system, because Meteor Packages are Isomorph, they have the ability to share their code on client and server, like the SimpleSchema Package or many others. To make it simple for developers to use it, it's an complete encapsulated system.
But to your question. There are a some of really valuable "ports" of Meteor Packages to plain npm architecture. For example you mentioned Tracker, so there is a npm package for that.
Tracker:
https://github.com/eface2face/meteor-tracker
(There is no Readme, but I guess it should be used, like Meteor Tracker, right?)
Minimongo:
https://www.npmjs.com/package/minimongo-standalone
... just to mention some...
To port a package you just need to extract the needed code, which don't depend on Meteor and other meteor packages and create a npm package of them.. So the code still behaves the same.. Just look at the Tracker code
You have to decide, why do you need meteor packages for your node/express application? And maybe there are already some better solutions in the npm world itself. If you really depend on major meteor packages, then just use Meteor ;)
I just get the same issue so i look around perhaps it's too late
However o found this https://www.npmjs.com/package/meteor-client-packages-meteor
Perhaps it could be helpful now
Or use this which the author recommends https://www.npmjs.com/package/meteor-webpack-client
Both are available..
Related
We have built a small-ish application using Aurelia, and would like to be able to integrate the app into a larger codebase. For example, it may be desirable to publish the Aurelia app on NPM, so other projects could integrate our code.
How can we build/publish the Aurelia app, so that it can be instantiated in a larger JavaScript application?
Typically, you wouldn't publish an entire Aurelia application to NPM, rather you would push plugins to NPM.
The simplest way to learn how to do this is to follow the example of the various Aurelia repos. We build the code in to multiple formats, but the most important are AMD and CommonJS (which is more important for your company is dependent on what tooling your company is using). Once you've built the code, the next step is to make sure your package.json file is set up correctly. It's best to copy the example of what we're doing in our own repos.
I would start by looking at either the dialog plugin or the templating-resources plugin. Both of these show good examples of how to publish your Aurelia plugin to NPM, whether it is a public or private npm feed.
https://github.com/aurelia/dialog/blob/master/package.json
https://github.com/aurelia/templating-resources/blob/master/package.json
Both of these plugins are set up to support Webpack, JSPM/SystemJS, and the Aurelia CLI out of the box.
I totally agree with #Ashley in not publishing larger applications to the global NPM registry. The big advantage of it is the simplicity of all that small packages which can be used to build large applications.
If you feel you got some reusable code, put in an own package and publish it.
Anyway, to give you an answer which does not require you to publish your complete app: you can include a complete repository (which is probobly what you are lookig for) in a different application via NPM.
npm install git://github.com/somegit/hubrepo.git
Or directly via the package.json:
"dependencies": {
"private-repo": "git+ssh://git#github.com:somegit/hubrepo.git#v1.0.0",
}
You can also do something similiar e.g. using JSPM. This would be simply:
jspm install your-app=github:OrgOrUser/your-app#your-branch
If you are facing long relative paths in your imports now, depending on your tooling, you may be interested in something like e.g. Resolving require paths with webpack which shows how to alias relative paths.
Sources/Links:
How to install a private NPM module without my own registry?
npm install private github repositories by dependency in package.json
Context
I'm using the aldeed:autoform package and found a couple bugs & filed PR for it(https://github.com/aldeed/meteor-autoform).
Aldeed being the only maintainer of a lot of popular packages ends up being the bottleneck for merging PR & following up with issues.
My solution was to fork his project & published my fork on atmosphere.
Naively, i just removed his package meteor remove aldeed:autoform and tried to add mine: meteor add metakungfu:autoform
When i load my app, i get the following error:
Package['aldeed:autoform'] returns the expected object, even though i removed the package.
For sake of completeness, i do use a bunch of other packages that depends on aldeed:autoform and my guess is that this is the reason why aldeed:autoform package is still present.
Questions:
What's the right way to use a fork of a package, when that package is dependency of other packages?
Is this the right way to solve my problem?
I've end up using mgp to manage the packages.
In order to solve my problem, i had to do two things:
First, add a git-packages.json in the root of your project that looks like this:
➜ cat git-packages.json
{
"aldeed:autoform": {
"git": "git#github.com:gregory/meteor-autoform.git",
"branch": "dev"
}
}
This will work locally, but if you deploy to heroku, the buildpack will need to install mgp & install the dependencies.
I just opened a PR to fix this
Fork all the dependencies and make them point to your fork.
Instead of publishing your own version of aldeed:autoform onto Atmosphere, you should rather use it as a local package, keeping its name intact. Meteor will look first for your local packages, before trying to fetch from Atmosphere.
That way, all your other packages that depend on it will use your local version.
To do that, see: Why does Meteor's aldeed/meteor-tabular package get stuck processing and never render a result?
Reference: Meteor Guide > Build > Writing Atmosphere Packages > Overriding packages with a local version
I noticed that somehow there is no packages folder in my newly created Meteor 0.9 project. This means that it must be using package from the ~/.meteor things. However, I cannot work like this as I am hopping between machines all day and I would like the package to stay locally; like in the project folder itself.
In the previous Meteor 0.8.3 project, I manually created packages folder in the project and when I add package it went inside there (for example i can find collectionFs inside package/ in the project directory).
I want it to be like this. How can I do this safely?
You can still drop packages into the top-level "packages" directory inside your project and then run meteor add like usual. These packages are just treated as app-specific packages. Here are the docs about using packages. The relevant bit is quoted here:
In addition to the packages in the official Meteor release being used by your app, meteor list and meteor add also search the packages directory at the top of your app.
I think the idea was to delineate the stand-alone application code from 3rd party libraries. As a package author, this means there are less forks of my library with subtle changes floating around on Atmosphere. It also makes your apps a bit less prone to bugs (given the packages are stable), and encourages better package maintenance.
If you want to use local packages though, here is a good walk-through.
For NPM packages, also check out meteorhacks:npm | github
For the collectionFS, you have to use meteor 0.6 version.
You have to add new release file of meteor 0.6 version.
https://github.com/CollectionFS/Meteor-cfs-example-filemanager
I'm about to start digging into Meteor for real (instead of just reading about it). I'm a near-complete noob but I've at least determined I'm going to use Sublime Text as my editor vs webstorm. I know I need a git account (going Bitbucket there). What else?
Are yeoman, grunt, and bower, (and lineman?) which seem like the workflow tools of the day, also necessary for writing a non-trivial app? It seems like Meteor already does a lot of the main functionality of these tools.
Do I need a testing suite like Jasmine (at least to get started?)
Anything else I'm missing? I just want to get everything I need (yes, including a couple good Javascript books) before I start.
You'll need the basic elements you already have (node, npm, git and ruby). You seem to know a little bit about web apps so I'll try analogies.
Yeoman essential purpose is to scaffold, meteor will do a really basic scaffolding for you. If you want to have a more advanced scaffold tool I encourage you to try em : https://github.com/EventedMind/em by Chris matter.
Grunt basic tasks equivalents are handled by the meteor commands (server, livereload, build, deploy...)
Bower is a package manager, I highly encourage you to use meteorite and its repo atmosphere (https://atmospherejs.com/) as your package manager. Actually, meteorite commands (mrt) are going to replace meteor commands in your projects. Eventually, atmosphere and meteorite are going to be fold into the core of meteor. (see meteor roadmap : https://trello.com/b/hjBDflxp/meteor-roadmap)
(note that you can use npm packages to)
All the essential functionalities of Lineman are handled by meteor.
However, some tasks are NOT handled by meteor.
I run the classic compass watch on my sass folder.
A good testing framework for meteor is Laika : http://arunoda.github.io/laika/
To start, you can go to discover meteor : https://www.discovermeteor.com/. For more advanced learning; go to evented mind : https://www.eventedmind.com/
The first thing you want to learn is how to handle iron-router
EDIT
There is now two major resources to start :
https://guide.meteor.com/
https://themeteorchef.com/
Iron router has been replaced by flow router ; there is a guide to use it :
https://kadira.io/academy/meteor-routing-guide
To manage scss :
https://atmospherejs.com/fourseven/scss
The view layer :
React replaced Blaze
So to preface my question, I'm coming from a Java back-end developer perspective, where we use Maven to build. I have worked on testing on a server-side Node project we recently developed, but now I'm moving on to setting up testing on our front-end JavaScript client. I'm not very well-versed in front-end development and this is really my first foray into that.
All that being said, I'm thinking I'm going to use the following technology stack for our front-end testing: Eclipse IDE, Maven build process, Mocha testing framework, Chai assertion framework, Nock HTTP mocking framework, Sinon mocking/spying/stubbing framework, Rewire dependency injection framework. That all should be fine, and since that's the stack we use for our Node project, I would like to keep the front-end setup as similar as possible.
So, this is where my knowledge breaks down, though. I cannot seem to understand the difference in dependency management between our Node project and our front-end JavaScript project. I cannot see why I would not continue to use NPM, integrated into our Maven build, to handle dependency management and installation.
I see many people advocating Bower, but after looking at its page and docs, I still am not seeing what niche it fills that NPM would not. I am seeing a lot of adamant rejection of NPM insofar as browser dependency management goes; the main reasoning being that NPM is designed for server-side Node projects, and not for the front-end space. But who cares? Regardless of its initial design's intentions, if it does what I need it to do, where is the downside?
Please approach this "question" as if I am a complete newbie. I have realized as I've gone through this process and research, that I have very large dearths of knowledge in regards to the front-end side of things. With that being said, be as specific and thorough as possible in your answers, please. I would be happy to share project configuration and such, as needed, in order to help paint a picture of the space I'm in. Thanks for any feedback!
Bower and NPM do work differently.
NPM is very powerful and great at what it does. However, you won't find many client-side packages in there; most of them are there because they work in Node too. (For example, Underscore.JS and the JADE template engine.)
That's why you have Bower, which has the majority of the client-side packages. It has many jQuery plugins, templating engines, CSS frameworks, etc. Don't expect to find such packages in NPM.
You can work fine with both. I do so. :)
Traditionally, many web development projects combined npm and Bower. npm was used to manage back-end dependencies, while Bower was used for front-end dependencies. In fact, you needed to use npm in order to install Bower in the first place.
Although Bower’s advantages were compelling, they are now provided by other tools, namely npm, Yarn and webpack. While the open source project is still maintained, its creators decided to deprecate it, and advise how to migrate to other solutions—namely Yarn and webpack.
more explanation