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

Re: [jslint] Tolerate

Expand Messages
  • ScottJ
    [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
    Message 1 of 18 , Sep 2, 2011
    • 0 Attachment
      [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
      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.
      Message 2 of 18 , Sep 5, 2011
      • 0 Attachment
        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]
      • 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 3 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 4 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 5 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.