engine is merged to devel!

[David Glasser]

After quite a lot of work (primarily by Avital, who's currently on a
well-deserved vacation), the Engine project has been merged to devel!

Here are the immediate benefits that you can when running out of a
checkout of devel:

*** Packages can depend on npm modules

Just put `Npm.depends` function calls inside your package.js, and then
use `Npm.require` to require the modules. See the mongo-livedata or
coffeescript packages for examples. (One restriction for now: if you
use architecture-specific npm modules, you'll still end up with your
development OS's modules when you bundle or deploy.)

*** Apps can contain packages in a directory called "packages"

This is a first step towards a supported way to distribute packages
outside of a Meteor release. For now, you can have packages in your
app (or symlinks from your app's package dir to some other directory).
I expect Meteorite will change once this is released to use this
instead of APP/.meteor/meteorite/package.

*** Tests are run with a new "meteor test-packages" subcommand

You used to run package tests by cd'ing into a package dir and running
it like an app. This new command lets you run tests on a few packages
at a time without having to run on all the packages, and lets you run
tests on your app packages as well.


*** All JS files are wrapped in closures (so top-level "var"s are now
file-local).




Additionally, there has been a major overhaul of the release process and how
installation and "meteor update" works. Apps can be pinned to particular
releases (though this is ignored if you're running Meteor from a git checkout)
and you may can have multiple releases installed in parallel. The bulk of
Meteor's code is installed in your home directory at ~/.meteor/ instead of
globally. Some aspects of this are not yet finalized (and will be before the
next release), but all aspects relating to running Meteor from a checkout should
work. I'll send another message to the list when this stuff is ready
to be tested ---
one exciting aspect is that it will make it much easier for us to create release
candidates.

Docs have not been fully updated yet (eg, Npm is not documented).

Let me know if you see any problems!

--dave

[Dror Matalon]

Are packages server only at this point or can they include both client
and server components?

> --
> You received this message because you are subscribed to the Google Groups "meteor-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[fritz....@gmail.com]

I suppose to closure-wrapping applies to the developer's code. I guess code already wrapped gets "double-wrapped"?

[David Glasser]

Client and server.

[David Glasser]

Yeah.

--

[Tim Heckel]

This is grand....but one question...the 'pinning' of the meteor releases is something that meteorite has been doing as well....this release seems to be bringing the two closer together....I suspect meteorite will likely not need to "download the development bundle" anymore once this release is pushed because core meteor will install its versions locally instead of globally, essentially duplicating what mrt had been solving.

so...mrt and meteor seem to be coming very close together -- are there plans to do a final merge and then deprecate mrt? What about atmosphere?

[Dror Matalon]

So you can mimic the behavior inside an application:client, server,
public, etc by using the same directory structure inside a package?

[Nick Martin]

Yup, thats the plan! https://trello.com/card/package-system-overhaul-officially-open-package-system-up-to-community/508721606e02bb9d570016ae/9

--

[David Glasser]

It's not based on the directory structure; packages declare how they
are put together in a `package.js` file (none of this has changed
actually, it's how internal packages have worked for ages).

We probably aren't going to spend too much effort documenting the
package.js API right now because it is likely to change before
third-party package distribution is fully supported... we've been
using it for a year and we're aware of its rough edges :)

[David Glasser]

That's right. Meteorite is a great tool and I'm really glad that Tom
and Mike and the rest of the community built it and have been
supporting it for the past year. But my personal hope is that most of
the features added by Meteorite will fit well into Meteor itself,
fully supported in core. 0.6.0 implements a few of Meteorite's
features: the ability to pin apps to specific Meteor releases (instead
of just having a single global installation), and the ability to have
per-app packages. 0.6.0 won't implement third-party package
downloading or publishing, so Meteorite will continue to be a great
tool for those uses until we have finished our roadmap plan to fully
incorporate third-party packages into core:
https://trello.com/card/package-system-overhaul-officially-open-package-system-up-to-community/508721606e02bb9d570016ae/9

--dave

On Wed, Mar 20, 2013 at 9:39 AM, Tim Heckel <timh...@gmail.com> wrote:

[Dror Matalon]

Ah, looking at package.js is what I was looking for and in there I see:
api.use(['random', 'ejson', 'json', 'underscore', 'minimongo',
'logging', 'livedata'],
['client', 'server']);
api.add_files('mongo_driver.js', 'server');
api.add_files('local_collection_driver.js', ['client', 'server']);
...

So at this point, do you recommend third party usage of the package
system, or should we hold off till it's more settled?

[David Glasser]

Well, this is basically the same system that folks on Atmosphere have
been using for months. And my expectation is that when the new system
comes out, you might have to rewrite the package.js a little and do
something slightly different for exporting global symbols, but the
bulk of the package code shouldn't need to change.

[Geoff Jacobsen]

Has the order in which files are loaded changed because of this? My <root>/lib dir is now loaded part way through instead of first; is this intended?

[David Glasser]

Can you provide a reproduction example? I'm not seeing that here.

[Geoff Jacobsen]

My mistake; I had an error an miss read the app.json file thinking the order had changed. The problem was I had a "var" in front of a top level Object and the new function wrapping code caused it to no longer be global.

Sorry for wasting your time.

You received this message because you are subscribed to a topic in the Google Groups "meteor-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-core/74t2dC9DU94/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to meteor-core...@googlegroups.com.

[David Glasser]

Not a waste at all! :)

[xray]

So how do coffeescript files are handled since coffeescript compiler wraps the files automatically? Are they also double-wrapped?

[xray]

Also, what would be the best practice to export / import classes / APIs in coffeescript now with new wrapping? I tried upgrading couple of apps to devel branch and everything stopped working due to scoping issues, do we just go with the usual (exports ? this).Module = Module or is there something else that's a best practice? Thanks!

[Andrew Wilcox]

On Thursday, March 21, 2013 11:51:39 AM UTC-4, xray wrote:

Also, what would be the best practice to export / import classes / APIs in coffeescript now with new wrapping? I tried upgrading couple of apps to devel branch and everything stopped working due to scoping issues

What scoping issues did you run into?  Can you give an example?

[Maxime Quandalle]

Le jeudi 21 mars 2013 16:27:15 UTC+1, xray a écrit :

So how do coffeescript files are handled since coffeescript compiler wraps the files automatically? Are they also double-wrapped?

The coffeescript package disable the coffee wrapper with the `bare` option, http://coffeescript.org/#usage

[xray]

E.g. in the observatory package logger is defined as "class TLog" which now became invisible from other files, whereas previously due to "Meteor concatenates everything together into one huge javascript" it just worked. For now doing the (exports ? this).TLog = TLog fixes it but it's still an issue with multi-file modules.

[xray]

PS Actually, it doesn't on the server, just on the client

[Andrew Wilcox]

What scoping issues did you run into?  Can you give an example?

E.g. in the observatory package logger is defined as "class TLog" which now became invisible from other files, whereas previously due to "Meteor concatenates everything together into one huge javascript" it just worked. For now doing the (exports ? this).TLog = TLog fixes it but it's still an issue with multi-file modules.

Where is this code?  Can you provide a link?

 

[xray]

https://github.com/jhoxray/observatory/blob/master/logging/observatory.coffee

Thanks!

[xray]

... or just do mrt add observatory into any mrt project and try calling logger = TLog.getLogger()

[Andrew Wilcox]

E.g. in the observatory package logger is defined as "class TLog" which now became invisible from other files, whereas previously due to "Meteor concatenates everything together into one huge javascript" it just worked. For now doing the (exports ? this).TLog = TLog fixes it but it's still an issue with multi-file modules.

Ah, I had been wondering why adding a closure wrapper had made a difference to CoffeeScript, since by default CoffeeScript generates its own closure wrapper.  But it turns out that the coffeescript package uses the "bare" option (https://github.com/meteor/meteor/blob/master/packages/coffeescript/package.js#L13), so developers who are using the package (as opposed to compiling CoffeeScript to JavaScript themselves, where they would normally get the wrapper), will now see a difference.

However the global namespace on both the client and server is available in this at the top level, so all you need to do is:

class TLog ...

this.TLog = TLog

[xray]

Right. Where it gets slightly more complex is with "modules" spread around several files - I was wrapping stuff into things like 

ModuleName = ModuleName ? {}

_.extend ModuleName,

# first source file

 class One...

# second source file

 class Two...

just putting this.ModuleName in every file does not work, so need to either expose every class explicitly or think about other (better) alternatives

[Andrew Wilcox]

 

just putting this.ModuleName in every file does not work

Try this:

ModuleName = (this.ModuleName or= {})

[David Glasser]

Right, my understanding is that to get globals out of a package in CoffeeScript, assigning to (exports ? this), or maybe just @, will work.

Geoff is in the middle of some experimental work to more generally improve namespacing in Meteor, and we talked yesterday about making sure that whatever plan we end up implementing works for CoffeeScript packages too. (Peek at the linker branch for an initial implementation.)

[Andrew Wilcox]

On Thursday, March 21, 2013 4:04:07 PM UTC-4, David Glasser wrote:

Right, my understanding is that to get globals out of a package in CoffeeScript, assigning to (exports ? this), or maybe just @, will work.

exports is not a NodeJS global like console or setTimeout; it only exists in modules that have been loaded with require.  (And since Meteor packages are not require'd, exports is undefined).

However, if you make a plain function call foo() without specifying this with .call, .apply, or by making a method call, this becomes the global object in both NodeJS and the browser.

And so,

@foo = 123

at the top level sets global.foo in NodeJS and window.foo in the browser.

[David Glasser]

Ah yes, that's what I tested last week :)