-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,4 +28,3 @@ if (!args.quiet) { | |
|
||
// pass the arguments to the cli module | ||
cli.execute(args, notifier.packageFile) | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,10 +1,10 @@ | ||
fs = require 'fs' | ||
W = require 'when' | ||
nodefn = require 'when/node' | ||
guard = require 'when/guard' | ||
keys = require 'when/keys' | ||
fs = require 'fs' | ||
W = require 'when' | ||
nodefn = require 'when/node' | ||
guard = require 'when/guard' | ||
keys = require 'when/keys' | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
notslang
Author
Collaborator
|
||
sequence = require 'when/sequence' | ||
mkdirp = require 'mkdirp' | ||
mkdirp = require 'mkdirp' | ||
|
||
FSParser = require '../fs_parser' | ||
Compiler = require '../compiler' | ||
|
@@ -18,23 +18,20 @@ class Compile | |
|
||
###* | ||
* Creates a new instance of the compile class. | ||
* | ||
* - makes a new fs parser instance | ||
* - makes a new compiler instance | ||
* - makes a new instance of each extension, with error detection. | ||
* this must happen every compile pass to clear lingering context | ||
* | ||
* @param {Function} roots - instance of the base roots class | ||
* @param {Function} roots - instance of the base roots class | ||
### | ||
|
||
constructor: (@roots) -> | ||
@extensions = @roots.extensions.instantiate() | ||
@fs_parser = new FSParser(@roots, @extensions) | ||
@compiler = new Compiler(@roots, @extensions) | ||
|
||
###* | ||
* Compiles the project. This process includes the following steps: | ||
* | ||
* - execute user before hooks if present | ||
* - parse the project, sort files into categories | ||
* - create the folder structure | ||
|
@@ -59,7 +56,6 @@ class Compile | |
|
||
###* | ||
* Calls any user-provided before hooks with the roots context. | ||
* | ||
* @private | ||
### | ||
|
||
|
@@ -68,7 +64,6 @@ class Compile | |
|
||
###* | ||
* Calls any user-provided after hooks with the roots context. | ||
* | ||
* @private | ||
### | ||
|
||
|
@@ -77,12 +72,10 @@ class Compile | |
|
||
###* | ||
* Checks to ensure the requested hook(s) is/are present, then calls them, | ||
* whether there was an array of hooks provided or just a single hook. | ||
* | ||
* @private | ||
* | ||
* @param {Array|Function} hook - a function or array of functions | ||
whether there was an array of hooks provided or just a single hook. | ||
* @param {Array|Function} hook - a function or array of functions | ||
* @return {Promise} promise for resolved hooks | ||
* @private | ||
### | ||
|
||
hook_method = (hook) -> | ||
|
@@ -99,8 +92,7 @@ class Compile | |
|
||
###* | ||
* If present, runs an async-compatible `setup` function in each extension, | ||
* ensuring that any asynchrnonous setup the extension needs is completed. | ||
* | ||
ensuring that any asynchrnonous setup the extension needs is completed. | ||
* @return {Promise} a promise that the extension setup is finished | ||
### | ||
|
||
|
@@ -109,11 +101,10 @@ class Compile | |
W.map(req_setup, ((ext) -> ext.setup())) | ||
|
||
###* | ||
* Creates the nested folder structure for a project. First, creates an array | ||
* of just the output paths, then creates the base public folder, then | ||
* sequentially walks through the folders and creates them all. | ||
* | ||
* @param {Object} ast - roots ast | ||
* Creates the nested folder structure for a project. First, creates an | ||
array of just the output paths, then creates the base public folder, then | ||
sequentially walks through the folders and creates them all. | ||
* @param {Object} ast - roots ast | ||
### | ||
|
||
create_folders = (ast) -> | ||
|
@@ -125,28 +116,26 @@ class Compile | |
|
||
###* | ||
* Files are processed by category, and each category can be processed in | ||
* One of two ways: parallel or ordered. Parallel processed categories will | ||
* crunch through their files as quickly as possible, starting immediately. | ||
* Ordered categories will parallel compile all the files in the category, but | ||
* wait until one category is finished before moving to the next one. | ||
* | ||
* An example use for each of these is client templates and dynamic content. | ||
* With client templates, they do not depend on any other compile process so | ||
* they are a great fit for parallel. For dynamic content, the front matter must | ||
* be parsed then available in normal templates, which means all dynamic content | ||
* must be finished parsing before normal content starts. For this reason, dynamic | ||
* content has to be ordered so it is placed before the normal compiles. | ||
* | ||
* So what this function does is first distinguishes ordered or parallel for each | ||
* extension, then pushes a compile task for that extension onto the appropriate | ||
* stack. The compile task just grabs the files from the category and runs them | ||
* each through the compiler's `compile` method. Then when they are finished, it | ||
* runs the after category hook. | ||
* | ||
* Once the ordered and parallel stacks are full of tasks, they are run. Ordered | ||
* gets sequenced so they run in order, and parallel runs (surprise) in parallel. | ||
* | ||
* @param {Object} ast - roots ast | ||
One of two ways: parallel or ordered. Parallel processed categories will | ||
crunch through their files as quickly as possible, starting immediately. | ||
Ordered categories will parallel compile all the files in the category, | ||
but wait until one category is finished before moving to the next one. An | ||
example use for each of these is client templates and dynamic content. | ||
With client templates, they do not depend on any other compile process so | ||
they are a great fit for parallel. For dynamic content, the front matter | ||
must be parsed then available in normal templates, which means all | ||
dynamic content must be finished parsing before normal content starts. | ||
* For this reason, dynamic content has to be ordered so it is placed before | ||
the normal compiles. So what this function does is first distinguishes | ||
ordered or parallel for each extension, then pushes a compile task for | ||
that extension onto the appropriate stack. The compile task just grabs | ||
the files from the category and runs them each through the compiler's | ||
`compile` method. Then when they are finished, it runs the after category | ||
hook. | ||
* Once the ordered and parallel stacks are full of tasks, they are run. | ||
Ordered gets sequenced so they run in order, and parallel runs (surprise) | ||
in parallel. | ||
* @param {Object} ast - roots ast | ||
### | ||
|
||
process_files = (ast) -> | ||
|
@@ -179,16 +168,14 @@ class Compile | |
parallel: W.all(parallel) | ||
|
||
###* | ||
* Sometimes extensions prevent file writes and leave behind empty | ||
* folders. The client templates extension is a good example. No matter | ||
* how it happens, there should not be any empty folders in the output, | ||
* so this method gets rid of them if they exist. | ||
* | ||
* Sometimes extensions prevent file writes and leave behind empty folders. | ||
The client templates extension is a good example. No matter how it | ||
happens, there should not be any empty folders in the output, so this | ||
method gets rid of them if they exist. | ||
* The way this is done is *very* hacky, but it is the speediest way. It | ||
* tries to delete every folder, and if it succeeds, it means the folder was | ||
* empty, as trying to remove a directory with contents throws an error (which | ||
* we ignore using an empty callback). | ||
* | ||
tries to delete every folder, and if it succeeds, it means the folder was | ||
empty, as trying to remove a directory with contents throws an error | ||
(which we ignore using an empty callback). | ||
* @private | ||
### | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
path = require 'path' | ||
path = require 'path' | ||
Roots = require '../' | ||
rimraf = require 'rimraf' | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
path = require('path') | ||
path = require('path') | ||
Roots = require('../') | ||
|
||
module.exports = (args, cli)-> | ||
|
8 comments
on commit 6544413
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.
SO, I find these commits happening across multiple projects as more and more code gets written. These "whitespace" changes are hard to always catch in code review thus these massive whitespace cleanup PR's.
If you are going to accept this @Jenius I would say that it needs to be paired with a test to prevent these errors in the future.
See this PR for how to
marionettejs/backbone.marionette@ce62531
It then puts the responsibility on the contributor to use proper white-space.
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.
+1 for that. most of it should be enforced by the .editorconfig
, but it's a great idea to have travis monitor it.
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 is only enforced by .editorconfig
if they have it enabled and that is a big if
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.
yeah, exactly why travis is a good idea for 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.
It seems like, looking through this discussion you linked @slang800, both the author of the guide and jashkenas agreed that an uninterrupted series of variable declarations do usually look better aligned correctly. This is the exact way that I treat the declarations here -- the only ones that get aligned are the variables in a big uninterrupted block at the top of files.
polarmobile/coffeescript-style-guide#2 (comment)
Again, I prefer doing it this way, your link shows that I am clearly not the only one, so unless you have some really major objections let's keep it this way.
As for the whitespace thing, I think maybe having it run coffeelint before the tests might be a good idea. I'll tinker around with a setup like that this week sometime!
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.
Yes, nobody questions that aligned variables look good (even I think they look pretty), but it's balancing that decorative formatting with:
- increased maintenance
- difficulty of dealing with edge cases (like when one variable is way longer than the others)
- the way it screws up diffs when you need to add or remove whitespace from like 5 lines just because the longest variable in that block was removed or renamed.
- defining rules to describe when to align, and when it goes too far (both styleguide rules and linter rules)
This is why it hasn't been added to the styleguide yet - it makes formatting a lot more complicated...
IMO, we should develop a way for editors to apply styles like aligning assignments as a view that is independent of the code. That way the code could be treated as data, while the editor displays it according to the user's preferences... might have to look at that once I start using atom.
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 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 mean a package that edits the underlying code (I've seen plenty of those) - I mean one that changes the way that you see the code (adjusting it to whatever your preferences are), while leaving the actual source the same.
I know that you do not, but I like having my variables aligned up top, so I'd like to keep this style