Skip to content
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

Merged
merged 9 commits into from
Sep 18, 2016
Merged

Modules documentation #4309

merged 9 commits into from
Sep 18, 2016

Conversation

GeoffreyBooth
Copy link
Collaborator

First draft. Relies on #4308.

@GeoffreyBooth
Copy link
Collaborator Author

For whatever reason, the JavaScript syntax highlighting doesn’t treat import and export as keywords:

image

@lydell
Copy link
Collaborator

lydell commented Sep 15, 2016

Looks nice!

Did we discuss somewhere else something about documenting --bare+import/export stuff?

<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.
Copy link
Collaborator

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 '*')
Copy link
Collaborator

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...

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

@vendethiel
Copy link
Collaborator

@lydell we just said it'd be nice to document it, IIRC.

@GeoffreyBooth
Copy link
Collaborator Author

@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
Copy link
Collaborator Author

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.

Copy link
Collaborator

@lydell lydell Sep 16, 2016

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> '

Copy link
Collaborator Author

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.

Copy link
Collaborator

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",
Copy link
Collaborator

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.

Copy link
Collaborator

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.
Copy link
Collaborator

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?

Copy link
Collaborator

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.

Copy link
Collaborator Author

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?

Copy link
Collaborator

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.

Copy link
Collaborator Author

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
Copy link
Collaborator

@lydell lydell Sep 16, 2016

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>{
Copy link
Collaborator

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.

@lydell
Copy link
Collaborator

lydell commented Sep 16, 2016

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?

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.

Copy link
Collaborator Author

@GeoffreyBooth GeoffreyBooth left a 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.

@GeoffreyBooth
Copy link
Collaborator Author

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.

@lydell lydell merged commit a8b77fb into jashkenas:master Sep 18, 2016
@GeoffreyBooth
Copy link
Collaborator Author

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” . . .

@lydell
Copy link
Collaborator

lydell commented Sep 18, 2016

Sweet! Is there anything else to do before cutting a release?

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.

I was just noticing that the introduction at the top of the docs says that CoffeeScript “will work in every JavaScript runtime” . . .

Well, that’s not been true since yield was added …

@GeoffreyBooth GeoffreyBooth deleted the modules-docs branch September 18, 2016 19:14
@jashkenas
Copy link
Owner

Well, that’s not been true since yield was added …

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.

@GeoffreyBooth
Copy link
Collaborator Author

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)”.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants