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

Replace JSChecker with Java version that plugs into compiler #41

Closed
hochhaus opened this issue Apr 29, 2016 · 4 comments
Closed

Replace JSChecker with Java version that plugs into compiler #41

hochhaus opened this issue Apr 29, 2016 · 4 comments
Assignees

Comments

@hochhaus
Copy link
Contributor

The current linter rule (closure_js_lint_test) uses the deprecated python closure-linter instead of the the new linter.jar (which is open sourced in the closure-compiler repository). The new linter has better support for ES6.

Can closure_js_lint_test be upgraded to use the new linter?

@jart jart self-assigned this May 3, 2016
@jart
Copy link
Contributor

jart commented May 3, 2016

This isn't actually going to be able to lint Closure Style due to a bug google/closure-compiler/pull/1768. This linter also doesn't check things like how two blank lines need to be before members, and three blank lines need to be before constructors. So I don't think it's really a replacement for the Python linter quite yet.

However this would be REALLY GOOD for incrementally checking the syntax of JavaScript code, because it goes lightning fast. So I'm repurposing this bug.

@jart jart changed the title Convert closure_js_lint_test to use linter.jar Replace JSChecker with Java version that plugs into compiler May 3, 2016
@hochhaus
Copy link
Contributor Author

hochhaus commented May 3, 2016

@jart Thanks.

I was under the impression from the following resources that linter.jar/clang-format was the new best practice internally at Google.

Am I moving too quickly in assuming that gjslint is deprecated / is in the process of being deprecated? To the best of your knowledge, do any plans exist to update gjslint with support for ES6? Should new code be written per the formatting guidelines of gjslint or linter.jar/clang-format?

Would clang-format (in addition to linter.jar) address your concerns about blank lines before members/constructors?

@jart
Copy link
Contributor

jart commented May 3, 2016

I don't know what's up with linter.jar but there's other stuff I'm already doing like jschecker.py. So I'm thinking we shouldn't use linter.jar. We could just write a Java program that plugs directly in the Closure Compiler, does the linting, validation, strict dependency checking, and all that good stuff. What do you think?

@hochhaus
Copy link
Contributor Author

hochhaus commented May 3, 2016

@jart Thanks, that sounds good to me.

jart added a commit to jart/rules_closure that referenced this issue May 4, 2016
jart added a commit to jart/rules_closure that referenced this issue May 4, 2016
jart added a commit to jart/rules_closure that referenced this issue May 4, 2016
jart added a commit to jart/rules_closure that referenced this issue May 4, 2016
jart added a commit to jart/rules_closure that referenced this issue May 4, 2016
jart added a commit to jart/rules_closure that referenced this issue May 4, 2016
@jart jart closed this as completed in 2d96850 May 4, 2016
ptmphuong pushed a commit to ptmphuong/rules_closure that referenced this issue Dec 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants