I have installed http://atmospherejs.com/mrt/natural by 'meteor add mrt:natural' (I am using Meteor 0.9.1). It seems to be installed ok, but the 'usage' says to simply call :
natural = Natural
This doesn't work when applied on the server or client side. I'm sure this must be so obvious as I can't see anyone else having the problem...
Yes, I am pretty new to Meteor.
This package doesn't seem to be maintained (last update 6 Jun 2013). There's also no need for it to be, since it's a simple wrapper for a Npm package, which can be now loaded in a better way.
Add npm package to your app with
meteor add meteorhacks:npm
and then create packages.json file with natural specified as per documentation. Then you'll be able to require natural with Meteor.npmRequire('natural');.
Related
I'm new to developing with Meteor and node-based apps.
I intend to create a PR for a problem i noticed in Rocket.Chat.
I git cloned the Rocket.Chat dev branch and made a change to a certain file:
https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-oembed/client/oembedImageWidget.html
After that i ran the build-script successfully. My build started, but the change is not included.
Using the Chrome Dev Tools to inspect the change, i still see the original unchanged code.
I know it's a rather generic question and i'm sure the solution is kind of stupid, but any idea why ?
Thank you.
Kind regards
It looks like the file you modified is in the packages directory. This is dealt with differently.
Check the .meteor/packages files to see if this package is referenced, if it is, then it will install the package from the atmosphere package management system.
Here the steps required to make your changes work...
1) Edit the .meteor/packages file and change the reference to rocketchat:oembed to be simply oembed
2) Edit the file packages/rocketchat-oembed/package.js and do the same thing, change rocketchat:oembed to be simply oembed
Package.describe({
name: 'oembed',
version: '0.0.1',
summary: 'Message pre-processor that insert oEmbed widget in template',
git: ''
});
I think you can leave the directory names as is.
Meteor will now use your local package instead of going out to get the published version of it
In addition to #Mikkel's answer: I think you don't have to change package name, but just change its version. That should be enough for Meteor to rebuild this package from its source and you won't have any dependency issues.
I am developing a small meteor package, and I know that, to be consistent with the builds, meteor will create a .versions file in my package when I publish it.
That's fine, and I understand that, but, as the .versions should go in my version control (git) and I would like to commit the release before publishing it, is there a way to update the .versions package before publishing?
Also, the .versions file has a reference to the package itself. Is this necessary? If I'm developing version x.y.z of a package, why do I need to update both the package.js and the .versions file to reflect x.y.z?
Thanks,
Oliver
I don't think there's a need to add it to version control b/c I don't think the set of calculated versions means anything in a stand-alone package outside of the context of a meteor project. I'm not really sure what the file is used for at all since it doesn't show up in .meteor/packages when you install the package. It might just be nothing more than a by-product of running the solver.
So I never check .versions into version control and I haven't encountered any problems.
There are two command line programs to start/stop/manage your meteor app. There is meteor and there is mrt. As of the latest build (0.8.2 or so) it's really not clear what the difference is between these two, if any. Both seem to support the argument "help" like meteor help and mrt help. The output of both seems to be the same to me.
Sadly, I do not see a "clean" argument available when I check the help for either of these. What do I need to do if I want to achieve a clean build? One that would
Blow away all packages and re-install them
Blow away any compiled templates
Blow away all Sass/Less compiled output
I ask this because I find myself in some kind of dependency Hades right now and want out now.
Meteor is still in a pre-release state. So the idea of packages is (still as of this post) not officially supported, though it will be soon. The meteor community stepped in to build their own way to use 3rd party packages and this is what meteorite does.
Most of the commands you give to meteorite are eventually passed to meteor which is why you see the same output.
The only (main difference is) mrt add which checks atmospherejs.com for packages first.
These two will be merged very soon (there is a branch on meteor on github called packaging which seeks to achieve this)
The idea of 'clean' isn't really there in meteor because most of the stuff is based on hot code reloads, so when a file changes its completely scrapped/(cleaned) and rewritten.
If you change a bit of code it will rebuild all this unless you have a syntax error.
Nonetheless if you want to 'clean' the build from everything you would have to do this in two steps (the meteor part and the meteorite part)
This erases some stuff in the hidden .meteor folder
meteor reset
Delete everything in ~/.meteorite/packages
Delete all symlinks only in your projects /packages folder. Be careful not to delete the folders because these will have been put in by you/whoever made your project and wouldn't be from atmosphere or meteor
Then run mrt update to reinstall all the atmosphere packages from scratch
Since Meteor 0.6.0+ supports npm packages directly, is Meteorite still relevant, and would there be any advantage/disadvantage to using it?
Meteorite is definitely still relevant and recent talks from meteor team indicate it will be folded into meteor itself eventually.
Meteorite does more than NPM, it also takes client side 3rd party libraries and specifies how they get integrated into a meteor app. In this aspect it serves the same purpose as yeoman/bower. 3rd party client side libraries like x-editable, sugar.js, moment.js, etc dont really belong in NPM, but you also shouldnt have to manually incorporate them into your meteor project either. See this comment from the meteor team: https://github.com/meteor/meteor/pull/516#issuecomment-12919473
Meteorite doesnt provide the full functionality of NPM. With just meteor, you cant just require a NPM package in your app and use it, even in 0.6.0+ you still have to make a package and an api wrapper. If you wanted to use a certain NPM and it was already wrapped and shared on meteorite, that would in effect provide a NPM 'proxy' via a meteorite package. Like this package https://atmosphere.meteor.com/package/ncp
I would suggest using meteorite for the capabilities you gain beyond meteor itself. However, be aware that this is an area in great flux so you may have to rework/adjust your project in the near term. IMO if you are building more than simplistic apps, you'll definitely want meteorite for the ease of incorporating 3rd party libraries.
Meteorite is still relevant at this point. Even though NPM packages are supported in meteor there isn't a community repo to add packages from (http://atmosphere.meteor.com)
Even though NPM modules can now be added they still need to be made to work with meteor.
Meteor code uses fibers to allow sync code to run so each NPM module being used still needs a package to let it be used in meteor which can make it easier to use (by allowing fibers code to be used in a project) with minor editing. Currently these packages have no other community place to go besides the atmosphere repo.
Now you can have full access to NPM.
Just do meteor add meteorhacks:npm
See my article: Complete NPM Integration to Meteor
I can add a package to a custom checkout of meteor as outlined in How to build a Meteor smart package
But this doesn't really work when developing with others.
I'm wondering if there's a way to do it within a project? A-la the old Rails vendor/plugins? If not, perhaps it could be something the devs might want to implement..
If you need others to use your package but you don't want your package in Meteor, then you could just fork the Meteor repo and work on your fork instead of Meteor itself. That way, the others can clone your repo instead of Meteor...