Analyze Build Redux

[ajmueller]

Before the current iteration of the build system was built by @kamsar, we had an "analyze" build. That build went the way of the Dodo due to the driver architecture of the build process (so @kamsar if this idea is totally impossible, let me know), but I think it may be worth discussing again considering our recent internal discussions around practice groups and standards. Those standards could be more easily enforced with a build process for analysis, especially during code reviews. Some ideas and packages to use:

• Check unused CSS (thanks to @chadian for this one)
• Validate HTML after we temporarily convert our PHP templates to HTML
• JSHint for linting. Though many of us use a linter in our text editors already, having it as part of an analysis build would make for quick diagnostics during code reviews.
• Enforce CSS rules
• Visual regression testing using tools that Micah showed at PDX Sass in February

Thoughts?

[kamsar]

tbh I think any sort of analysis is a bit toothless as long as it's something optional you have to run (which is why it was removed during the build update).

IMO, if analysis is brought in it should run as part of the build and fail the build if analysis finds problems. Yes, you may have to disable some analysis features you dont agree with. But the old analyze build was never used.

The scripts should support this idea fairly easily.

[jbascue]

That model works for Visual Studio.

I miss the analysis and liked where Alex was going with the idea of
bringing it back, but I really like the idea of it being integrated right
into the build like this a lot. It enforces standards that much better.
On Sat, Apr 4, 2015 at 1:48 PM Kam Figy notifications@github.com wrote:

tbh I think any sort of analysis is a bit toothless as long as it's
something optional you have to run (which is why it was removed during the
build update).

IMO, if analysis is brought in it should run as part of the build and
fail the build if analysis finds problems. Yes, you may have to disable
some analysis features you dont agree with. But the old analyze build was
never used.

The scripts should support this idea fairly easily.

—
Reply to this email directly or view it on GitHub
#131 (comment)
.

[stoff]

Just would like to add to the chorus of "should be part of the build", however, we'd want to look a little more closely at annoyances this may cause in a watch build.

Specifically I'm thinking of times when an unnoticed JS error has stopped my watch and I don't notice until after I've already noticed the bad save, fixed the issue, and then refreshed my browser (only to discover, shock!, that my changes don't appear or that the css is not reloading)

Also useful might be writing a log since there are times when the error report may be longer than the user's terminal buffer.

[ajmueller]

👍 for writing to a log. That was one feature about our previous analyze build that I wasn't a fan of: only console output.

[kamsar]

$ build-dev.command > build.log :)

Saucy console tricks aside, if your error list is really longer than your terminal buffer uh...that's a problem.

[ajmueller]

Ooooh, nice. That would seemingly be easy to incorporate into the shell scripts then, right? I personally find it nicer to read a file in a text editor than a console window, so having a consistent log would be nice.

[kamsar]

http://en.wikipedia.org/wiki/Tee_%28command%29 would work to send to console AND log
Some of the validators may also have built in file logging options.