From the Meteor docs:
Give users of this package access to another package (by passing in the string packagename) or a collection of packages (by passing in an array of strings [packagename1, packagename2]).
I have no idea what it means.
From this question I know that imply can be employed with use.
What does api.imply do?
What's exactly the difference between api.use and api.imply?
api.use gives a package access to other packages exported symbols.
For example you need to api.use("random") (see how it's done in the accounts-base package) if you want to use the Random symbol in a package code (see how the random package.js is api.exporting Random).
However, meteor adding accounts-base wouldn't give your whole application access to its used packages (random in this case). If your app needs random, you'd still need to meteor add it.
api.imply on the other hand, gives the whole application access to that package exported symbols.
For example, see how accounts-google is api.implying accounts-base.
accounts-base is responsible for exporting the Accounts symbol, when you meteor add accounts-google, not only does accounts-base is also added in your application dependencies, but accounts-base symbols are also made available in your app, specifically because it was implied.
accounts-base is both using Accounts in its own code (api.use) and exporting its dependencies symbols to the whole app (api.imply).
api.imply can be used to make "shadow packages" that are just pulling in some other packages.
For example, at some point MDG renamed the showdown package to markdown, they could just have stated to meteor remove showdown && meteor add markdown, but it would have required some actions on end users.
What they did instead is keeping the showdown package and just make it implying the new markdown package.
If you have something in your app that consumes api from package:name and you install just package package:dependant which has a package:name as a dependency, but you don't use imply here, your api from package:name will not work in the app. It will work only in package:dependant package. You need use imply if you want to use something from package:name outside your package:dependant
I don't know if this is clear ;)
Related
Is it possible to get a list of all available packages and their configuration within a running MeteorJS app.
I don't mean the CLI command meteor list but something that could let me check if certain packages are available or not and change the programs behaviour accordingly.
Yes.
Using code from the meteorhacks SSR package as an example, you can see that it does this to check for the existence of the Jade package:
if(Package['mquandalle:jade-compiler']) {
Compilers.jade = Package['mquandalle:jade-compiler'].JadeCompiler;
}
The caveat is that the other package has to be added first.
Two part question.
1- I managed to create a package with meteor but I had to explicitly assign to the output, now if the package is not available I'll get an error.
How to check if the package is available or enabled and if so use it in code or template.
2- let's say I have 2 packages, projects and tasks, each of them can work separately from the other.
I want to create a projects if project package is available.
I want to create a tasks if task package is available.
I want to assign tasks to projects if these both packages are available.
How to achieve such flexibility with decoupled packages with meteor.
The Package object (on the global scope) list all the installed packages for an application.
You could test the presence of one of your package by doing something like this:
//will return an Object if package is loaded or undefined
if(Package['package:name']) {
//...
}
I'm using Velocity with the mike:mocha framework and the chai assertions. Everything is working great, but when it comes time to do stubbing, mocking and spying, I've hit a bit of a roadblock. These aren't core features of mike:mocha or chai, so I found practicalmeteor:chai, which should/may have added spies.
My first stab at finding out whether this is true was to write the following code:
it 'calls update when both documents are present but different', ->
spies.create('log', console, 'log')
which gives me:
ReferenceError: spies is not defined
at packages/velocity:test-proxy/tests/mocha/server/charger_server_doc_spec.coffee:88:9
at wrappedFunc (packages/mike:mocha/server.js:200:1)
at runWithEnvironment (packages/mike:mocha/server.js:156:1)
That implies to me that I've misunderstood what practicalmeteor:chai provides, however, the code I showed in the first example is copied verbatim from the README.
Question: Any tips on getting this to work? Is it a load order issue? The code on Github shows spies and so on are implemented in this package. So I'm a bit stuck.
Thanks!
The package practicalmeteor:chai does not include the practicalmeteor:sinon package which is required to get the spies API included.
They are separate packages because you may not have to use spies when creating basic tests with chai.
If you look at the package.js file in the practicalmeteor:chai package, it does not include the sinon files.
So, just running meteor add practicalmeteor:sinon should solve your problem.
I created a package for atmospherejs.com.
Everything worked as expected but now I want to delete it.
How can I remove it from atmosphere?
I found the following explanation but I guess its not up to date:
https://github.com/oortcloud/atmosphere/issues/53
Prevent packages from showing up in meteor search with meteor admin set-unmigrated. Checkout their blogpost on here.
A new administrative command hides packages from the results of meteor search and meteor show. This is designed to remove mrt-era packages that didn't correctly auto-migrate into the new package system and for cases where authors have changed the name of a package and don't want new developers using the old name. To hide a package, run meteor admin set-unmigrated. Please note that hiding a package does not prevent users from explicitly adding it.
There is no way to do so on the new packageserver as mentioned by tmeasday at the end of the issue.
https://github.com/oortcloud/atmosphere/issues/53#issuecomment-54010716
When construction meteor packages you can add files like this:
api.use('fourseven:scss#0.9.4', ['client', 'server']);
You can also tell meteor to give the package user access to other packages like this:
api.imply('fourseven:scss#0.9.4', ['client', 'server']);
In the documentation it's not clear if implying a package also makes it available. For instance, I'm not sure if it is redundant to do this:
api.use('fourseven:scss#0.9.4', ['client', 'server']);
api.imply('fourseven:scss#0.9.4', ['client', 'server']);
I've just tested this use case with a couple packages of mine and I can assert that implying a package doesn't make it available automatically in the package source.
So it means that
api.use("foo:bar#x.y.z");
api.imply("foo:bar#x.y.z");
is NOT redundant if you intend to use and reference foo:bar in the current package source.
You can think of api.imply as an api.use for the app context that has no impact on the current package context.
I've heard that some time in the future they plan to integrate a package-like API for the app context, which is going to be useful to address load order among other things.