20

How can I omit the automatic closure wrappers that hides my variables from the global scope?

(function() {
  // my compiled code
}).call(this);

Just playing around with CoffeeScript+SproutCore, and of course, I'd prefer to leave the scope as it is: in this case there is no need to protect anything from overwriting.

I know I can use @ or this. at the declaration, but that's not too elegant.

Zeppelin
  • 284
  • 2
  • 5
  • You should _really_ avoid doing that. You don't want your local variables to leak into the global scope. – shesek Feb 15 '12 at 04:11
  • 5
    @shesek maybe he is using a bundler? which already wraps everything in a scope? Or uses RequireJS? I think that wrapper scope should be optional. – benqus Sep 07 '13 at 15:31
  • @benqus - agreed, I either use my own wrapper or combine multiple files into one big wrapper using grunt for example. But otherwise if you just find it ugly or something, you shouldn't omit it. – Richard de Wit Dec 11 '14 at 13:10

2 Answers2

42

Quick and dirty solution: Use the console flag -b (bare). Warning: Kittens will die if you do that!

Clean solution: Don't do that.

Usage: coffee [options] path/to/script.coffee

  -c, --compile      compile to JavaScript and save as .js files
  -i, --interactive  run an interactive CoffeeScript REPL
  -o, --output       set the directory for compiled JavaScript
  -j, --join         concatenate the scripts before compiling
  -w, --watch        watch scripts for changes, and recompile
  -p, --print        print the compiled JavaScript to stdout
  -l, --lint         pipe the compiled JavaScript through JSLint
  -s, --stdio        listen for and compile scripts over stdio
  -e, --eval         compile a string from the command line
  -r, --require      require a library before executing your script
  -b, --bare         compile without the top-level function wrapper
  -t, --tokens       print the tokens that the lexer produces
  -n, --nodes        print the parse tree that Jison produces
      --nodejs       pass options through to the "node" binary
  -v, --version      display CoffeeScript version
  -h, --help         display this help message
thejh
  • 44,854
  • 16
  • 96
  • 107
  • 11
    This answer is correct, but it's worth noting that `-b` is heavily discouraged in nearly all cases. [Here's why](http://stackoverflow.com/questions/5211638/pattern-for-coffeescript-modules/5212449#5212449). – Trevor Burnham Apr 17 '11 at 15:49
  • How would you do this from sinatra of setting coffee -b – coool Jan 20 '12 at 20:38
  • -1 for not mentioning its awfully wrong to do so. _edit:_ hrr, it won't let me -1 for some reason – shesek Feb 15 '12 at 04:11
  • 4
    bare shouldn't necessarily be always discouraged. There is real use case for server side use with node.js – Tony Jul 24 '13 at 20:32
  • @Tony, I wrangle my server globals using `@`, like `@test -> 'bla'` in one file and `test()` in a later file. – Cees Timmerman Feb 26 '16 at 17:02
7

I used another option which was to attach my global variables to the global object in the scope of my function. I attached mine to the 'window'. This keeps your JavaScript encapsulated and only exposes the variable that you need in the global scope.

user699242
  • 1,833
  • 4
  • 21
  • 31