Loading ...
Sorry, an error occurred while loading the content.

RE: [jslint] Tolerate

Expand Messages
  • Rob Richardson
    Kent, We do this too, but don t run it inside Selenium inside a browser. Rather we run JSLint inside cscript.exe or V8 or rhino or JScript. It makes tests
    Message 1 of 18 , Sep 5, 2011
    • 0 Attachment
      Kent,

      We do this too, but don't run it inside Selenium inside a browser. Rather
      we run JSLint inside cscript.exe or V8 or rhino or JScript. It makes tests
      run MUCH faster. We also get the build system to update jslint.js
      automatically every so often. I'm with you on the value of updating
      frequently, and also avoiding the update periodically.

      Rob


      -----Original Message-----
      From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
      Behalf Of Kent Davidson
      Sent: Monday, September 05, 2011 10:15 AM
      To: jslint_com@yahoogroups.com
      Subject: Re: [jslint] Tolerate

      Scott,

      What we do at my company is pull down versions of the jslint code and site
      and then host it internally on test web servers (e.g.
      test.example.com/jslint.com/), and then use Selenium to automatically place
      our JS code into it and check for errors.

      The nice part about this is that we can reliably run our tests and get known
      responses from the javascript engine of the browser, as well as not
      depending on internet connectivity to actually run the tests.

      Then, you can update the jslint code as often as needed and update your
      tests accordingly.

      One of the greatest things about jslint is that it's written in JavaScript
      and is essentially encapsulated in a single file. While it's nice to keep up
      to date with Douglas' changes, it's also nice to not have to do so always.

      Cheers,

      -Kent.

      On Sep 3, 2011, at 2:32 AM, ScottJ wrote:

      > [I realize I'm late to the discussion, and I apologize if I'm reopening
      old wounds.]
      >
      > Referring to the change on June 9 that inverted the semantics of many of
      the options.
      >
      > It is customary these days to provide some kind of deprecation period when
      making significant changes like this. Without it, I have to simultaneously
      update the jslint version and every single js source file as one big change.
      >
      > Even if jslint is version-controlled in the same repository as all my
      source files, it still means that I have a broken repo until I have updated
      each and every one of my source files, which might take days or even weeks.
      >
      > It would be better to allow both an old and new syntax for at least one
      version of jslint. Then I can use that version during a transition period
      while I update my js sources at my leisure. (In this specific case, I liked
      the suggestion for "allow"/"deny" instead of true/false to distinguish the
      new semantics from the old.)
      >
      > Without a promise and future expectation of that, it puts up a huge
      barrier to adopting a jslint workflow in any reasonably large organization.
      And that would be a shame, as jslint is a valuable tool.
      >
      > Thanks for your consideration,
      > Scott Johnson
      >
      > --- In jslint_com@yahoogroups.com, "Rob Richardson" <erobrich@...> wrote:
      > >
      > > I'm sure I'll unleash the wrath, but this is such a fail. Epic fail. You
      > > asked for a disruption in the force, you got it.
      >
      >

      --
      Kent Davidson
      Market Ruler, LLC
      Marketing Power Tools
      http://marketruler.com/?_cr=efoot
      +1 866-622-8636 x88






      [Non-text portions of this message have been removed]



      ------------------------------------

      Yahoo! Groups Links
    • ScottJ
      I keep a local copy of jslint too (as part of jslint_on_rails) but that doesn t solve the problem here. The issue is that one change to jslint has caused all
      Message 2 of 18 , Sep 6, 2011
      • 0 Attachment
        I keep a local copy of jslint too (as part of jslint_on_rails) but that doesn't solve the problem here. The issue is that one change to jslint has caused all kinds of js sources to start failing, with no option for backward compatibility. That means I have to update jslint plus *all* my js sources as one big atomic change.

        It would be preferable to be able to update one js source file, then checkin. Update another, checkin. Etc. With dozens of js source files originally written by dozens of authors, it is a real headache to get all of them updated together.

        The reality is that I will have to disable jslint in our workflow for some time, or kludge up some way to keep multiple versions of jslint active and have each source file specify which version it is compatible with.

        Neither of those are good options.

        Bottom line: A professional tool like jslint should not change so drastically without any regard for backward compatibility. That pushes people away from it, and that is a real shame.


        --- In jslint_com@yahoogroups.com, Kent Davidson <kent@...> wrote:
        >
        > Scott,
        >
        > What we do at my company is pull down versions of the jslint code and site and then host it internally on test web servers (e.g. test.example.com/jslint.com/), and then use Selenium to automatically place our JS code into it and check for errors.
      • Kent Davidson
        Sorry for misinterpreting your post. I see the issue. Is it possible to simply pre-process the legacy JavaScript before plugging it through JSLint as was
        Message 3 of 18 , Sep 6, 2011
        • 0 Attachment
          Sorry for misinterpreting your post. I see the issue.

          Is it possible to simply pre-process the legacy JavaScript before plugging it through JSLint as was outlined by Merlin above to "fix" it?

          -Kent.


          On Sep 6, 2011, at 2:41 PM, ScottJ wrote:

          > I keep a local copy of jslint too (as part of jslint_on_rails) but that doesn't solve the problem here. The issue is that one change to jslint has caused all kinds of js sources to start failing, with no option for backward compatibility. That means I have to update jslint plus *all* my js sources as one big atomic change.
          >
          > It would be preferable to be able to update one js source file, then checkin. Update another, checkin. Etc. With dozens of js source files originally written by dozens of authors, it is a real headache to get all of them updated together.
          >
          > The reality is that I will have to disable jslint in our workflow for some time, or kludge up some way to keep multiple versions of jslint active and have each source file specify which version it is compatible with.
          >
          > Neither of those are good options.
          >
          > Bottom line: A professional tool like jslint should not change so drastically without any regard for backward compatibility. That pushes people away from it, and that is a real shame.
          >
          > --- In jslint_com@yahoogroups.com, Kent Davidson <kent@...> wrote:
          > >
          > > Scott,
          > >
          > > What we do at my company is pull down versions of the jslint code and site and then host it internally on test web servers (e.g. test.example.com/jslint.com/), and then use Selenium to automatically place our JS code into it and check for errors.
          >
          >

          --
          Kent Davidson
          Market Ruler, LLC
          Marketing Power Tools
          http://marketruler.com/?_cr=efoot
          +1 866-622-8636 x88






          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.