jekyll / jekyll-coffeescript

A CoffeeScript converter for Jekyll.
MIT License
53 stars 20 forks source link

Compile coffeescript with compile options. #8

Closed ir-g closed 8 years ago

ir-g commented 10 years ago

Re: jekyll/jekyll#3012 Cc: @parkr

It would be great if a coffeescript or sass file could be compiled with options which are declared via the yaml front matter and/or config.yml.

The ability for my coffeescript scripts to no longer be wrapped in a function wrapper, as below, would be really useful, as while I am a massive fan of using Jekyll unmodified (as in Github Pages), I would have to turn to other compilation methods, where I need complete control over my site, where using Jekyll + Coffeescript.

function(){
//Generated coffeescript code is here
}.call(this);

Thoughts?

ir-g commented 9 years ago

@parkr ?

parkr commented 9 years ago

The CoffeeScript converter isn't passed options. It gets the site configuration and the content so your switches would have to be on every CoffeeScript file rather than just one or a handful. That said, the :christmas_tree: of configuration options is already out of hand and I'd be really hesitant to add any more configuration options lest we end up unusable like Mutt. If you think the CoffeeScript defaults are wrong, I'd encourage you to ask them about why they chose to, for example, surround the compiled JavaScript in an automatically-executing function. I'm sure some of it has to do with polluting the global variable namespace etc etc so in general I'm all for it. If you think something about their defaults warrants changing for everyone who uses CoffeeScript in their Jekyll sites, then we can certainly set an option on our side, no problemo. But every user will have to live with that option. The way Jekyll is structured does not allow options to be specified for a given file. I honestly like it that way – solves a lot of potential confusion.

What is your compelling reason to strip out the function(){ }.call(this);? What about it makes it unusable?

ir-g commented 9 years ago

Thanks for your response.

In various environments, where JS functions are called on launch of pages, as is the case with Source Game Server loading screens, etc.(TF2, Garry's Mod, Etc.), it is vital that function(){ }.call(this); is removed.

Furthermore, I believe that the code you write should be the code you get. Coffeescript saves me time, but only while it generates the code I expect, as according to coffeescript.org.

I entirely understand the preference for a global set of coffeescript configuration options, and I don't mind that one bit. It would be great to see a change such that function(){ }.call(this); isn't the compulsory result.

Thoughts, @parkr ?

parkr commented 9 years ago

In various environments, where JS functions are called on launch of pages, as is the case with Source Game Server loading screens, etc.(TF2, Garry's Mod, Etc.), it is vital that function(){ }.call(this); is removed.

Forgive my naïveté, but what about that function makes it impossible to work with? I'm looking for technical details so I can understand the implications. Would you mind providing further insight?

Maybe it's worth setting this value to false always. I will read up on why the function is there.

ir-g commented 9 years ago

@parkr function(){}.call(this); removes the immediate availability of the functions enclosed, and therefore in some environments the Generated JS from Jekyll-Coffeescript can be rendered useless in selected old/obscure browsers.

Futhermore, I don't quite understand why the function(){}.call(this); wrapper is used, when I know no good reason for it, nor why it is used. Please could you elaborate on why it is used, if possible.

josh commented 9 years ago

function(){}.call(this); removes the immediate availability of the functions enclosed, and therefore in some environments the Generated JS from Jekyll-Coffeescript can be rendered useless in selected old/obscure browsers.

I'm not sure what you mean by these. You probably want to be exporting properties you want exposed on global.

window.foo = ->

# or this is always your global scope which works in node and the browser
this.foo = ->
# or
@foo = ->

Also from the CoffeeScript readme.

If you'd like to create top-level variables for other scripts to use, attach them as properties on window, or on the exports object in CommonJS. The existential operator (covered below), gives you a reliable way to figure out where to add them; if you're targeting both CommonJS and the browser: exports ? this

File lexical scoping is very much a core feature of the CoffeeScript language.

FWIW, the use of "bare" is highly discouraged in the Rails Asset Pipeline stack.

ir-g commented 9 years ago

@parkr @josh Hmm, still, would it be feasible for an option to be made available, to choose whether or not to have the function(){}.call(this); wrapper?

parkr commented 9 years ago

I'm leaning pretty heavily toward no. If functions and variables can be exposed without the options, which they can be using window or document, then I see no practical use-case for removing the self-executing function. You can always write whatever it is you would want this for in a JavaScript file, and use CoffeeScript for the remainder of your application's code.

jekyllbot commented 8 years ago

This issue has been automatically marked as stale because it has not been commented on for at least three months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If you can still reproduce this error on the

3.1-stable
or
master
branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider building it first as a plugin. Jekyll 3 introduced hooks which provide convenient access points throughout the Jekyll build pipeline whereby most needs can be fulfilled. If this is something that cannot be built as a plugin, then please provide more information about why in order to keep this issue open.

Thank you for all your contributions.