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

Re: [jslint] Tolerate

Expand Messages
  • kaichen67@yahoo.de
    ... Please reverse this step. It s a punishment to wade through hundreds of files and change the options meaning. Even more, because of the good parts preset
    Message 1 of 18 , Jun 9, 2011
      > The options have been revised to make their definitions more
      > consistent. JSLint will now do the Good Parts by
      > default. The options will now relax its rules, making it more
      > tolerant of popular bad practices. The option onevar
      > has been removed, replaced with the option vars, which has the
      > opposite polarity. These options have reversed their
      > meanings:

      Please reverse this step. It's a punishment to wade through hundreds
      of files and change the options meaning. Even more, because of the
      "good parts" preset one might have to add several options and remove
      certain others. Even with search & replace it's a lot of work, because
      it has to be done for each reversed option and one has to track which
      opts already were changed.

      If several people add to a project, some might add a file with the
      option's "new" meaning while other files still have the old opts
      meaning. What a mess.

      /me thinks new option names would have been a better and more
      backward compatible solution. Maybe as a first step the occurrence of
      an old option could set the new option accordingly and an jslint could
      give an additional warning. In a few month support for old names can
      be removed.
    • Rob Richardson
      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. I grant the options are now much
      Message 2 of 18 , Jun 9, 2011
        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.

        I grant the options are now much more clear for the new user, but for the
        mounds of existing code there is no backwards compatibility, and instantly
        the option does the opposite of what it did yesterday. The change is
        undiscoverable, not backwards compatible, and thus defeats the very purpose
        for which the tool was created.

        You noted you were worried about the disruption. All the replies focused on
        mechanisms to facilitate the new, clearer interface while maintaining
        backwards compatibility. The solution chosen is an instant break with no
        compatibility, and very confusing for anyone who used any previous version
        with any degree of skill. Jslint.com's main page says nothing of this
        change, and there is no release notes documenting it anywhere. If I wasn't
        receiving these emails or happened upon the github repo, I wouldn't even
        know that I instantly will get opposite results from my trusted tool.

        Some examples of the confusion:
        - If I have /*JSLINT regexp:true /* does that mean that I am tolerating them
        or that I haven't fixed the file yet?
        - If I check out a previous release's code that passed JSLint last week,
        today it will fail because all these options I had previously asked for I'm
        now unintentionally asking against and not because my code is broken.
        - If I copy a block of code from "JavaScript: The Good Parts" and paste it
        into the website, I will unknowingly have exactly the opposite desired
        behavior as documented in the book.

        Where do we go from here? No solution seems good. If you put it back, all
        of us that are 1/2 way through the arduous task of recomplying are borked.
        If you leave the new interface in place, the second half of the arduous task
        is before us and is still no less confusing. If you move to a more
        backwards-safe system, everyone who's converting will need to start over.
        The only clear solution seems to be downloading and versioning JSLint with
        my source so I know which interface I was using at any given time, or moving
        to one of the many JSLint clones that focus more on developer happiness and
        less on alienating their user-base.

        I typically choose nearly identical options for 90% of my files. Perhaps I
        need to stop putting those options in the files for consistency of
        execution, and instead pass them as options as I call JSHint. Perhaps I
        need to build a yet-another-wrapper that'll copy my favorite options into
        place and patch the engine before calling JSLint Prime. Perhaps I'll write
        a patch that will allow for /*JSLINT ver:2011-09-23 ... */ specifying the
        interface version and contribute the patch to JSLint's github project. Oh
        wait, you don't allow contributions.

        Rob


        -----Original Message-----
        From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
        Behalf Of Douglas Crockford
        Sent: Thursday, June 09, 2011 12:38 AM
        To: jslint_com@yahoogroups.com
        Subject: [jslint] Tolerate

        The options have been revised to make their definitions more consistent.
        JSLint will now do the Good Parts by default. The options will now relax its
        rules, making it more tolerant of popular bad practices. The option onevar
        has been removed, replaced with the option vars, which has the opposite
        polarity....
      • John Hawkinson
        Rob Richardson wrote on Thu, 9 Jun 2011 ... I think most of us have not begun the task, because we are optimistically hoping Douglas
        Message 3 of 18 , Jun 9, 2011
          Rob Richardson <erobrich@...> wrote on Thu, 9 Jun 2011
          at 11:54:39 -0700 in <007201cc26d6$b038a1a0$10a9e4e0$@org>:

          > Where do we go from here? No solution seems good. If you put it back, all
          > of us that are 1/2 way through the arduous task of recomplying are borked.
          > If you leave the new interface in place, the second half of the arduous task

          I think most of us have not begun the task, because we are optimistically
          hoping Douglas will revert his ill-considered decision. I think that is
          the best way forward.

          I hope those of you who are not posting in the public thread are
          sending private emails to Douglas so he has an accurate assessment
          of the reaction.

          Thanks.

          --jhawk@...
          John Hawkinson
        • spence.randall@ymail.com
          I fully understand that this doesn t appear to be the popular opinion, but I really like the new settings. Rather than having a directive at the top listing
          Message 4 of 18 , Jun 9, 2011
            I fully understand that this doesn't appear to be the popular opinion, but I really like the new settings. Rather than having a directive at the top listing all the good parts, my files can now simply have /*jslint browser: true, indent 4*/ and I am all set. Granted, I can fully understand the good points that many are making, a change of this magnitude can be arduous at best, just wanted to say that I for one appreciate the change.

            -Randall



            --- In jslint_com@yahoogroups.com, John Hawkinson <jhawk@...> wrote:
            >
            > Rob Richardson <erobrich@...> wrote on Thu, 9 Jun 2011
            > at 11:54:39 -0700 in <007201cc26d6$b038a1a0$10a9e4e0$@org>:
            >
            > > Where do we go from here? No solution seems good. If you put it back, all
            > > of us that are 1/2 way through the arduous task of recomplying are borked.
            > > If you leave the new interface in place, the second half of the arduous task
            >
            > I think most of us have not begun the task, because we are optimistically
            > hoping Douglas will revert his ill-considered decision. I think that is
            > the best way forward.
            >
            > I hope those of you who are not posting in the public thread are
            > sending private emails to Douglas so he has an accurate assessment
            > of the reaction.
            >
            > Thanks.
            >
            > --jhawk@...
            > John Hawkinson
            >
          • Merlin
            ... The recent changes have simplified the user interface, so I would not wish to see a reversion of all of the changes. The real problem is in the way JSLint
            Message 5 of 18 , Jun 10, 2011
              --- In jslint_com@yahoogroups.com, John Hawkinson <jhawk@...> wrote:
              > I think most of us have not begun the task, because we are optimistically
              > hoping Douglas will revert his ill-considered decision. I think that is
              > the best way forward.

              The recent changes have simplified the user interface, so I would not wish to see a reversion of all of the changes.

              The real problem is in the way JSLint now handles the /*jslint */ directive, particularly for those who have large numbers of files which use the directive.

              Although it is possible to edit the files, there is still the possibility of confusion between files that have and have not been edited. It would be much safer to leave the /*jslint */ directive with the original polarity convention, as a legacy/deprecated construct, and introduce a new version of the directive (e.g. /*options */) which would use the new polarity convention.

              It would then be perfectly clear what was intended. I think that such a change would only require fairly minor additions to the jslint.js function itself.

              That would give users time to convert from the old to new convention. After a certain period the old form could be phased out.
            • Satyam
              I agree. It would make a mess of any Version Control System, having all the files marked edited for no reason intrinsic to the application they belong to, by
              Message 6 of 18 , Jun 10, 2011
                I agree. It would make a mess of any Version Control System, having all
                the files marked edited for no reason intrinsic to the application they
                belong to, by committers other than those responsible for those files.

                Perhaps the /*jslint*/ directive could be followed by a version number:

                /*jslint:2 .... */ which would trigger the new meaning while no version
                number would default to version 1, the original meaning.

                El 10/06/2011 16:44, Merlin escribió:
                >
                >
                >
                > --- In jslint_com@yahoogroups.com
                > <mailto:jslint_com%40yahoogroups.com>, John Hawkinson <jhawk@...> wrote:
                > > I think most of us have not begun the task, because we are
                > optimistically
                > > hoping Douglas will revert his ill-considered decision. I think that is
                > > the best way forward.
                >
                > The recent changes have simplified the user interface, so I would not
                > wish to see a reversion of all of the changes.
                >
                > The real problem is in the way JSLint now handles the /*jslint */
                > directive, particularly for those who have large numbers of files
                > which use the directive.
                >
                > Although it is possible to edit the files, there is still the
                > possibility of confusion between files that have and have not been
                > edited. It would be much safer to leave the /*jslint */ directive with
                > the original polarity convention, as a legacy/deprecated construct,
                > and introduce a new version of the directive (e.g. /*options */) which
                > would use the new polarity convention.
                >
                > It would then be perfectly clear what was intended. I think that such
                > a change would only require fairly minor additions to the jslint.js
                > function itself.
                >
                > That would give users time to convert from the old to new convention.
                > After a certain period the old form could be phased out.
                >
                >
                > ------------------------------------------------------------------------
                >
                > No virus found in this message.
                > Checked by AVG - www.avg.com <http://www.avg.com>
                > Version: 10.0.1382 / Virus Database: 1513/3691 - Release Date: 06/09/11
                >


                [Non-text portions of this message have been removed]
              • Erik Eckhardt
                That gives me an idea. Why not /*jslintlegacy */ for the old style and /*jslint */ for the new?? It should not be hard for those needing backward compatibility
                Message 7 of 18 , Jun 10, 2011
                  That gives me an idea.

                  Why not /*jslintlegacy */ for the old style and /*jslint */ for the new?? It
                  should not be hard for those needing backward compatibility to do a global
                  search and replace to convert the one to the other. This is much simpler
                  than looking at each option individually, just at the comment start to be
                  sure what one is replacing is actually a comment and not somehow inside a
                  string or something.

                  On Fri, Jun 10, 2011 at 7:44 AM, Merlin <g7awz@...> wrote:

                  >
                  >
                  >
                  >
                  > --- In jslint_com@yahoogroups.com, John Hawkinson <jhawk@...> wrote:
                  > > I think most of us have not begun the task, because we are optimistically
                  > > hoping Douglas will revert his ill-considered decision. I think that is
                  > > the best way forward.
                  >
                  > The recent changes have simplified the user interface, so I would not wish
                  > to see a reversion of all of the changes.
                  >
                  > The real problem is in the way JSLint now handles the /*jslint */
                  > directive, particularly for those who have large numbers of files which use
                  > the directive.
                  >
                  > Although it is possible to edit the files, there is still the possibility
                  > of confusion between files that have and have not been edited. It would be
                  > much safer to leave the /*jslint */ directive with the original polarity
                  > convention, as a legacy/deprecated construct, and introduce a new version of
                  > the directive (e.g. /*options */) which would use the new polarity
                  > convention.
                  >
                  > It would then be perfectly clear what was intended. I think that such a
                  > change would only require fairly minor additions to the jslint.js function
                  > itself.
                  >
                  > That would give users time to convert from the old to new convention. After
                  > a certain period the old form could be phased out.
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • spence.randall@ymail.com
                  Excellent idea, this has my vote. -Randall
                  Message 8 of 18 , Jun 10, 2011
                    Excellent idea, this has my vote.

                    -Randall

                    --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
                    >
                    > That gives me an idea.
                    >
                    > Why not /*jslintlegacy */ for the old style and /*jslint */ for the new?? It
                    > should not be hard for those needing backward compatibility to do a global
                    > search and replace to convert the one to the other. This is much simpler
                    > than looking at each option individually, just at the comment start to be
                    > sure what one is replacing is actually a comment and not somehow inside a
                    > string or something.
                    >
                    > On Fri, Jun 10, 2011 at 7:44 AM, Merlin <g7awz@...> wrote:
                    >
                    > >
                    > >
                    > >
                    > >
                    > > --- In jslint_com@yahoogroups.com, John Hawkinson <jhawk@> wrote:
                    > > > I think most of us have not begun the task, because we are optimistically
                    > > > hoping Douglas will revert his ill-considered decision. I think that is
                    > > > the best way forward.
                    > >
                    > > The recent changes have simplified the user interface, so I would not wish
                    > > to see a reversion of all of the changes.
                    > >
                    > > The real problem is in the way JSLint now handles the /*jslint */
                    > > directive, particularly for those who have large numbers of files which use
                    > > the directive.
                    > >
                    > > Although it is possible to edit the files, there is still the possibility
                    > > of confusion between files that have and have not been edited. It would be
                    > > much safer to leave the /*jslint */ directive with the original polarity
                    > > convention, as a legacy/deprecated construct, and introduce a new version of
                    > > the directive (e.g. /*options */) which would use the new polarity
                    > > convention.
                    > >
                    > > It would then be perfectly clear what was intended. I think that such a
                    > > change would only require fairly minor additions to the jslint.js function
                    > > itself.
                    > >
                    > > That would give users time to convert from the old to new convention. After
                    > > a certain period the old form could be phased out.
                    > >
                    > >
                    > >
                    >
                    >
                    > [Non-text portions of this message have been removed]
                    >
                  • Ben White
                    I really appreciate the effort to standardize the options. I would suggest simply keeping the existing names and adding new ones that are a little more
                    Message 9 of 18 , Jun 10, 2011
                      I really appreciate the effort to standardize the options. I would suggest
                      simply keeping the existing names and adding new ones that are a little more
                      verbose.

                      tolerateBitwise
                      assumeNode
                      etc...

                      This way backwards compatibility is maintained and secondly there is no
                      confusion what true means.

                      Just my 2 cents.

                      Ben


                      [Non-text portions of this message have been removed]
                    • Merlin
                      ... There is a new version (10.3.2) of my Widget Tester Widget at http://tinyurl.com/5unocx . This should be compatible with the revised JSLint options. I ve
                      Message 10 of 18 , Jun 12, 2011
                        --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
                        >
                        > The options have been revised to make their definitions more consistent. JSLint will now do the Good Parts by default. The options will now relax its rules, making it more tolerant of popular bad practices. The option onevar has been removed, replaced with the option vars, which has the opposite polarity. These options have reversed their meanings:


                        There is a new version (10.3.2) of my Widget Tester Widget at http://tinyurl.com/5unocx .
                        This should be compatible with the revised JSLint options.

                        I've added a new "Assume legacy jslint directives" checkbox in the Operation preference pane. When checked, a filter is applied to the javascript text before it is submitted to JSLint. The filter maps the options in any /*jslint ... */ directives from the former convention to the current convention. Please let me know if you find any problems.

                        I have also made a JSLint Filter Widget which can be used to (permanently) convert javascript files. It converts any /*jslint ... */ directives from the former convention to the current convention. It can be downloaded from http://tinyurl.com/6ym8n3v .

                        Both Widgets require installation of the Yahoo! Widget Engine to run on Mac OS X or Windows. The Widgets can be unzipped to reveal the code.

                        I have not made much use of /*jslint ... */ directives in my own code, so I have very few files to test with. The filter code is quite simple and works for me, but I can't be sure that it will work in all circumstances. Please let me know if you find problems.

                        function filter(data) {
                        var lookFor = /\/\*jslint[\s\S]*?\*\//g;

                        return data.replace(lookFor, function (s) {
                        return s.replace(/strict\s*\:\s*true/, "sloppy: false").replace(/strict\s*\:\s*false/, "sloppy: true")
                        .replace(/onevar\s*\:\s*true/, "vars: false").replace(/onevar\s*\:\s*false/, "vars: true")
                        .replace(/(bitwise|newcap|nomen|plusplus|regexp|undef|white)\s*\:\s*true/, "$1: FALSE")
                        .replace(/(bitwise|newcap|nomen|plusplus|regexp|undef|white)\s*\:\s*false/, "$1: true")
                        .toLowerCase();
                        });
                        }
                      • Merlin
                        ... Here is an improved version of the filter function that should not disrupt line numbers: function filter(data) { var lookFor = / / *jslint[ s S]*? * //g;
                        Message 11 of 18 , Jun 12, 2011
                          --- In jslint_com@yahoogroups.com, "Merlin" <g7awz@...> wrote:
                          > I have also made a JSLint Filter Widget which can be used to (permanently) convert javascript files. It converts any /*jslint ... */ directives from the former convention to the current convention. It can be downloaded from http://tinyurl.com/6ym8n3v .

                          Here is an improved version of the filter function that should not disrupt line numbers:

                          function filter(data) {
                          var lookFor = /\/\*jslint[\s\S]*?\*\//g;

                          return data.replace(lookFor, function (s) {
                          return s.replace(/strict(\s*)\:(\s*)true/, "sloppy$1:$2false").replace(/strict(\s*)\:(\s*)false/, "sloppy$1:$2true")
                          .replace(/onevar(\s*)\:(\s*)true/, "vars$1:$2false").replace(/onevar(\s*)\:(\s*)false/, "vars$1:$2true")
                          .replace(/(bitwise|newcap|nomen|plusplus|regexp|undef|white)(\s*)\:(\s*)true/, "$1$2:$3FALSE")
                          .replace(/(bitwise|newcap|nomen|plusplus|regexp|undef|white)(\s*)\:(\s*)false/, "$1$2:$3true")
                          .toLowerCase();
                          });
                          }
                        • 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 12 of 18 , Sep 2, 2011
                            [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 13 of 18 , Sep 5, 2011
                              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 14 of 18 , Sep 5, 2011
                                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 15 of 18 , Sep 6, 2011
                                  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 16 of 18 , Sep 6, 2011
                                    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.