can linter.jar be included in compiler-latest.zip?

[Hochhaus, Andy]

Hello,

To make the new linter a bit easier to use would it be possible to
either include it in compiler-latest.zip or add a linter-latest.zip to
the downloads?

-Andy

[John Lenz]

Can you open a github issue for this?

-Andy

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/CAAhqAFr3MrHKnYdLKJ7caXLRfAbByf%3DH06ikVoZzffOURBoX0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Hochhaus, Andy]

On Thu, Jan 14, 2016 at 4:59 PM, John Lenz <conca...@gmail.com> wrote:
> Can you open a github issue for this?

Absolutely. Thanks.

https://github.com/google/closure-compiler/issues/1401

-Andy

[Peter StJ]

This is new to me, is this supposed to replace gjslinter? I built it from source, but it prints no help message(s). Any documentation on how to use it or how do you guys use it?

Thanks

[John Lenz]

Yes, this is slated to replace gjslint.  gjslint has no facilities for ES6.  Generally, it is expected that folks will use a code formatter such as clang-format with the new linter, so it doesn't bother you with things like "your text is misaligned".

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/f052cfd8-e07e-455f-ac3e-c1c125bef98b%40googlegroups.com.

[Tyler Breisacher]

We may end up putting the linter jar on dl.google.com but in the meantime you can get most of the same checks by passing --jscomp_warning=lintChecks to the compiler jar.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/CACHUifxvijCGF9WQMsOYbuKt_URjrgRyC8hCY%2B8paaeJftNPwA%40mail.gmail.com.

[Hochhaus, Andy]

On Fri, Jan 15, 2016 at 8:30 AM, 'Tyler Breisacher' via Closure
Compiler Discuss <closure-comp...@googlegroups.com> wrote:
> We may end up putting the linter jar on dl.google.com but in the meantime
> you can get most of the same checks by passing --jscomp_warning=lintChecks
> to the compiler jar.

Is it possible to use --jscomp_{warning,error}=lintChecks on a subset
of the compiled files?

My reason for asking is that our first party code cleanly lints.
However some of the third-party code we use does not. Therefore, using
linter.jar we are able to lint only first party files (but not 3rd
party files). Is such a configuration possible with lintChecks
directly?

-Andy

[Tyler Breisacher]

You can use the --hide_warnings_for flag but that will suppress all warnings in the third party code, not just the lint warnings. This might be okay if your third party code changes infrequently.

-Andy

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/CAAhqAFqKUaJwc8iEB2agtV%3DNYHJktbOxZq0Ehab6MviY_7X%3DYQ%40mail.gmail.com.

[John Munro]

Is there a way of turning off the linter for the closure library since that has thousands of warnings?  Or should I be working on fixing the warnings in the library code and submitting patches?

On Friday, January 15, 2016 at 12:13:14 PM UTC-5, Tyler Breisacher wrote:

You can use the --hide_warnings_for flag but that will suppress all warnings in the third party code, not just the lint warnings. This might be okay if your third party code changes infrequently.

On Fri, Jan 15, 2016 at 9:06 AM, Hochhaus, Andy <ahoc...@samegoal.com> wrote:

On Fri, Jan 15, 2016 at 8:30 AM, 'Tyler Breisacher' via Closure
Compiler Discuss <closure-comp...@googlegroups.com> wrote:
> We may end up putting the linter jar on dl.google.com but in the meantime
> you can get most of the same checks by passing --jscomp_warning=lintChecks
> to the compiler jar.

Is it possible to use --jscomp_{warning,error}=lintChecks on a subset
of the compiled files?

My reason for asking is that our first party code cleanly lints.
However some of the third-party code we use does not. Therefore, using
linter.jar we are able to lint only first party files (but not 3rd
party files). Is such a configuration possible with lintChecks
directly?

-Andy

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

[Tyler Breisacher]

I wouldn't bother fixing them unless you see one that seems to indicate a real bug in the code. Lint warnings show up on our internal code review tool so things get fixed gradually when the file is being modified anyway, rather than flooding the source control history with little nitpicky fixes.

You can --hide_warnings_for the entire Closure Library.

On Tue, Jan 19, 2016 at 8:48 AM, John Munro <ghos...@gmail.com> wrote:

Is there a way of turning off the linter for the closure library since that has thousands of warnings?  Or should I be working on fixing the warnings in the library code and submitting patches?

On Friday, January 15, 2016 at 12:13:14 PM UTC-5, Tyler Breisacher wrote:

You can use the --hide_warnings_for flag but that will suppress all warnings in the third party code, not just the lint warnings. This might be okay if your third party code changes infrequently.

On Fri, Jan 15, 2016 at 9:06 AM, Hochhaus, Andy <ahoc...@samegoal.com> wrote:

On Fri, Jan 15, 2016 at 8:30 AM, 'Tyler Breisacher' via Closure
Compiler Discuss <closure-comp...@googlegroups.com> wrote:
> We may end up putting the linter jar on dl.google.com but in the meantime
> you can get most of the same checks by passing --jscomp_warning=lintChecks
> to the compiler jar.

Is it possible to use --jscomp_{warning,error}=lintChecks on a subset
of the compiled files?

My reason for asking is that our first party code cleanly lints.
However some of the third-party code we use does not. Therefore, using
linter.jar we are able to lint only first party files (but not 3rd
party files). Is such a configuration possible with lintChecks
directly?

-Andy

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/CAAhqAFqKUaJwc8iEB2agtV%3DNYHJktbOxZq0Ehab6MviY_7X%3DYQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/2fd762ee-3f4d-4814-b9a0-d22fad8cb994%40googlegroups.com.

[Hochhaus, Andy]

On Tue, Jan 19, 2016 at 9:33 AM, 'Tyler Breisacher' via Closure Compiler Discuss <closure-comp...@googlegroups.com> wrote:
> I wouldn't bother fixing them unless you see one that seems to indicate a real bug in
> the code. Lint warnings show up on our internal code review tool so things get fixed
> gradually when the file is being modified anyway, rather than flooding the source control
> history with little nitpicky fixes.
>
> You can --hide_warnings_for the entire Closure Library.

I started using --hide_warnings_for=<closure-library-path> with relative success. It would be nice if the syntax of the flag would be extended to optionally specify which classes of warnings you wish to hide. If no warning classes were specified it could default to all warning classes (to maintain the current default).

For example, something like:

  --hide_warnings_for=<closure-library-path>:unnecessaryCasts,useOfGoogBase,extraRequire,lintChecks

-Andy

[Peter StJ]

I have incorporated the linter in the build process. Two things:

• would have been nice if it had at least '--help' so one could see if there are any options (maybe there are none?)
  
• using external formatting tool is great (in dart they have a tool integrated with the IDE, so the developer is never bothered with formatting, it just formats the file as you save), however clang google style is drastically different from what gjslint used to require and now each time a file is changed the commit is polluted with too many changes unrelated to the actual commit.
  

Never the less I think it is a move in the right direction (automatic formatting on save).

On Friday, 15 January 2016 18:06:40 UTC+2, John wrote:

Yes, this is slated to replace gjslint.  gjslint has no facilities for ES6.  Generally, it is expected that folks will use a code formatter such as clang-format with the new linter, so it doesn't bother you with things like "your text is misaligned".

On Fri, Jan 15, 2016 at 3:50 AM, Peter StJ <regard...@gmail.com> wrote:

This is new to me, is this supposed to replace gjslinter? I built it from source, but it prints no help message(s). Any documentation on how to use it or how do you guys use it?

Thanks

On Friday, 15 January 2016 00:53:42 UTC+2, Andy Hochhaus wrote:

Hello,

To make the new linter a bit easier to use would it be possible to
either include it in compiler-latest.zip or add a linter-latest.zip to
the downloads?

-Andy

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

[Hochhaus, Andy]

On Wed, Jan 20, 2016 at 5:24 AM, Peter StJ <regard...@gmail.com> wrote:
> using external formatting tool is great (in dart they have a tool integrated
> with the IDE, so the developer is never bothered with formatting, it just
> formats the file as you save), however clang google style is drastically
> different from what gjslint used to require and now each time a file is
> changed the commit is polluted with too many changes unrelated to the actual
> commit.

We did one large reformatting change to update to the clang google
formatting. This approach has the downside of causing a lot of churn
all at once, but it isolates that churn into a single commit. Then
going forward all new changes won't have any formatting noise.
-Andy