-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modules documentation #4309
Modules documentation #4309
Conversation
Looks nice! Did we discuss somewhere else something about documenting |
<p> | ||
Note that the CoffeeScript compiler <strong>does not resolve modules</strong>; writing an | ||
<code>import</code> or <code>export</code> statement in CoffeeScript will produce an | ||
<code>import</code> or <code>export</code> statement in the resulting output JavaScript. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resulting output JavaScript? I'd propose "resulting JavaScript" or "resulting output" or "JavaScript output" or...
@@ -115,7 +115,11 @@ exports.Lexer = class Lexer | |||
if id is 'from' and @tag() is 'YIELD' | |||
@token 'FROM', id | |||
return id.length | |||
if id is 'as' and (@seenImport or @seenExport) and @tag() in ['IDENTIFIER', 'IMPORT_ALL', 'EXPORT_ALL'] | |||
if id is 'as' and @seenImport and (@tag() is 'IDENTIFIER' or @value() is '*') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure why the commit from #4308 is here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was necessary to get my example code to compile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it can be rebased out now.
@lydell we just said it'd be nice to document it, IIRC. |
@lydell, good catch. Updated. I wonder if we really need to say anything else? I like the rather minimal documentation that lets the example speak for itself. Or should I link to something explaining what modules are, or to the MDN import or export pages, or anything like that? |
@@ -54,6 +54,10 @@ codeFor = -> | |||
js = js.replace /^\/\/ generated.*?\n/i, '' | |||
|
|||
cshtml = "<pre><code>#{hljs.highlight('coffeescript', cs).value}</code></pre>" | |||
# Temporary fix until highlight.js adds support for newer CoffeeScript reserved words |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lydell how do you feel about this? How important is clear highlighting? I feel like we don’t want to wait until highlight.js updates its definition for CoffeeScript, and then we update the version of highlight.js we’re using.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine to special-case here. However, I think we should use the power of regex instead of a for
loop ;)
cshtml = cshtml.replace /import|export|from|as|default/g, '<span class="reserved">$&</span> '
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They’re actually not the same. We need to search for the space after the keyword, or else as
matches within class="
. But if we replace including the space, we get <span class="reserved">as </span>
. Maybe this could be done with an even cleverer regex, but I’m not sure it’s worth the effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, I didn’t see that space! This should do the trick:
cshtml = cshtml.replace /(import|export|from|as|default) /g, '<span class="reserved">$1</span> '
@@ -14,7 +14,7 @@ | |||
"devDependencies": { | |||
"uglify-js": "~2.2", | |||
"jison": ">=0.2.0", | |||
"highlight.js": "~8.0.0", | |||
"highlight.js": "~9.6.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused. #3981 (comment):
Is there a reason we have this bower.json? It doesn’t seem to be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The bower.json
is (was) for people using Bower as part of their compilation steps. Not sure it's needed anymore.
be output without a <a href="#lexical-scope">top-level function safety wrapper</a>; | ||
in other words, importing or exporting modules will automatically trigger | ||
<a href="#usage">bare</a> mode for that file. This is because per the ES2015 spec, | ||
<code>import</code> or <code>export</code> statements must occur at the topmost scope. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that you link to other parts of the documentation. Here's a quote from the #lexical-scope
section:
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
That mentions even CommonJS – should it perhaps mention import/export as well?
Also, I'm having a hard time deciding where this --bare
stuff fits best – in the #modules
section, the #lexical-scope
section, the #usage section
(does the coffee --help
output need to be updated as well?), all of them … ? What's your opinion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--help
seems fine to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t understand exports ? this
. Is that even CoffeeScript? Shouldn’t it be something like exports ?= this
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is what is hinted as:
attach them as properties on window, or on the exports object
# Browser globals only:
window.myExport = myExport
# CommonJS only:
exports.myExport = myExport
# Support either:
global = exports ? window
global.myExport = myExport
# `this` at the top level is the global object. Theoretically support more stuff:
global = exports ? this
global.myExport = myExport
Not sure if we should go down this sub-quest of improving that paragraph of documentation “while at it,” or just leave it be and be happy with the addition of mentioning export
statements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There’s no convenient way to support all three. You either have to know you’re using modules or you’re targeting the browser/CommonJS. You can’t even do some kind of check as far as I’m aware, like “if export
is supported...”. I guess just leave it as I’ve amended it, with the mention of export
?
@@ -54,6 +54,10 @@ codeFor = -> | |||
js = js.replace /^\/\/ generated.*?\n/i, '' | |||
|
|||
cshtml = "<pre><code>#{hljs.highlight('coffeescript', cs).value}</code></pre>" | |||
# Temporary fix until highlight.js adds support for newer CoffeeScript reserved words |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine to special-case here. However, I think we should use the power of regex instead of a for
loop ;)
cshtml = cshtml.replace /import|export|from|as|default/g, '<span class="reserved">$&</span> '
} | ||
|
||
square = <span class="function"><span class="keyword">function</span><span class="params">(x)</span> {</span> | ||
square = <span class="function"><span class="keyword">function</span>(<span class="params">x</span>) </span>{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are all these little changing due to you updating highlight.js?
I think this PR will be easier to review if you leave out the compiled files. They will be committed when the 1.11.0 release is done.
I think it's good the way it is. You've matched the tone and style of the rest of the documentation nicely, I think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I’ve addressed all the notes so far.
Alright @lydell, anything else? I wish I could somehow mark your review as done. I think I might prefer the review style we were using in #4300, since when I would commit changes that addressed line notes, those comments would disappear from the stream. In this mode the comments stick around commit after commit, with no way to mark them as “closed” or addressed, as far as I can tell. |
Sweet! Is there anything else to do before cutting a release? I was just noticing that the introduction at the top of the docs says that CoffeeScript “will work in every JavaScript runtime” . . . |
I don’t think so. Last Friday I started plowing through the commit log since the last release (that’s one year ago!) to make a change log, but I didn’t get very far.
Well, that’s not been true since |
Maybe it should be, though? I kind of like the notion of CoffeeScript 1.X being super-compatible just-works-anywhere — even in bizarre environments like Adobe Illustrator ... and 2.X being the "modern" flavor. Probably too late for that though. |
A bit late since we added generators. Modules I don’t think anyone would expect to work without further build-chain steps. Maybe we should just add an asterisk after “every JavaScript runtime,” linking to a footnote or tooltip like “(except for certain ES2015+ features, modules and generators, that are opt-in by using the feature)”. |
First draft. Relies on #4308.