CS2 Discussion: Output: Drop top-level function safety wrapper?

[GeoffreyBooth]

CoffeeScript by default adds a top-level function safety wrapper around all the code in each file. It’s just (function(){ ... })();. It can be disabled by setting the --bare flag.

Per the ES2015 spec, import or export statements must appear at the topmost scope, and cannot be within a function block like this. So when modules support was added, we automatically set bare to enabled for any file with module statements.

For 2.0, do we want to get rid of this safety wrapper? ”Bare” mode would become the default, and we would remove the --bare flag as well. Is there any reason to keep them in an ESNext-outputting version of CoffeeScript?

[mrmowgli]

I understood the original intent of the closure, however I personally have never found it useful.

I can see it having being worked around in many situations, and if code relies upon the original behavior then that code would break.

Perhaps this could be kept, but on module definition removed? Or removed and allowed back by a flag, although flags seem to be no-no generally.

[GeoffreyBooth]

I’ve given this a lot of thought 🤔 and it occurs to me there is one big and probably fairly common use case where the safety wrapper is needed: people who concatenate the output of a bunch of compiled .coffee files. You know, the first example in the documentation:

coffee --compile --output lib/ src/

Without the safety wrapper, any variables declared at the top scope in one file would remain declared at the start of the next file, and so on. Obviously this isn’t an issue for a project using ES modules, so we’re fine ditching the safety wrapper there. But as a default for general projects, we should probably leave the safety wrapper as it is.

[coffeescriptbot]

Migrated to jashkenas/coffeescript#4934