Why meteor 0.6.0 wraps everything (function () {...})

Question

Starting with version 0.6.0, the meteor wraps each javascript file in (function () {...}). This makes sense for my own javascript files. But not for third-party libraries. For example. I am using sha3.js from crypto-js. This. located in the / lib client. It was excellent to 0.5.9. But now the functions from sha3 are no longer available.

Can I disable this packaging?

Answer 1

Function closures were first introduced on the server side (and only on the server) for two main reasons:

• Copied variables are a great way to avoid collisions of variables while saving simple variable names
• This was technically necessary for the Npm.require function Npm.require

One of the features of Node / Meteor is the ability to run the same file on the client and on the server. That is why the variable scope must have the same behavior on both the client and server, and why Meteor now also includes closing functions on the client.

Unable to disable packaging (without changing the Meteor/tools code).

This will be improved in the near future thanks to work on the linker branch , which will automatically solve your file dependencies (based on variable names), and then 1. include javascript files in the correct order. 2. Export the variables that are needed to the global scope.

Now you have to manually export the objects that should be in the global area.

Answer 2

You can use the undocumented bare (previously raw ) option before add_files :

 api.add_files([ 'sha3.js' ], 'client', {bare: true}); 

And it will not wrap the added file (s).

Answer 3

Meteor 0.6.0 introduces NPM compatibility , so finally you can officially use NPM Modules , which are added through meteor packets. The problem is that with globalized conflict coverage, conflicts arise when it comes to variable declarations, since the package is basically taken into account as if it were a file in your project

This only affects the server side code, but then if the server side code has been limited, the client side code will no longer be compatible, so the client side code will also be limited for consistency.

The solution is to globalize the variables as you expected in coffeescript by adding @ or removing var in javascript.

While I also believe that this upsets several client libraries (e.g. the x-editable and ace editor), a good solution is handled with a linker branch on the meteor so that files can be automatically scanned for dependencies, then automatically scale them.

This is discussed a little more: https://groups.google.com/forum/?fromgroups=#!topic/meteor-talk/gYgYhv88nB4