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

Re: Tolerate

Expand Messages
  • Merlin
    There is a new version (10.3.0) of my Widget Tester Widget at http://tinyurl.com/5unocx . This should be compatible with the revised JSLint options. Please
    Message 1 of 18 , Jun 9, 2011
    • 0 Attachment
      There is a new version (10.3.0) of my Widget Tester Widget at

      http://tinyurl.com/5unocx .

      This should be compatible with the revised JSLint options.

      Please let me know if you find any problems.

      --- 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:
      >
      > bitwise Tolerate bitwise operators
      > newcap Tolerate uncapitalized constructors
      > nomen Tolerate dangling _ in identifiers
      > plusplus Tolerate ++ and --
      > regexp Tolerate . and [^...] in /RegExp/
      > sloppy Tolerate missing 'use strict' pragma
      > undef Tolerate misordered definitions
      > vars Tolerate multiple var statements
      > white Tolerate sloppy spacing
      > The other options continue to work as before.
      > The Good Parts button is no longer needed and was removed.
      > Please let me know if you find any problems.
    • 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 2 of 18 , Jun 9, 2011
      • 0 Attachment
        > 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 3 of 18 , Jun 9, 2011
        • 0 Attachment
          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 4 of 18 , Jun 9, 2011
          • 0 Attachment
            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 5 of 18 , Jun 9, 2011
            • 0 Attachment
              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 6 of 18 , Jun 10, 2011
              • 0 Attachment
                --- 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 7 of 18 , Jun 10, 2011
                • 0 Attachment
                  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 8 of 18 , Jun 10, 2011
                  • 0 Attachment
                    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 9 of 18 , Jun 10, 2011
                    • 0 Attachment
                      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 10 of 18 , Jun 10, 2011
                      • 0 Attachment
                        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 11 of 18 , Jun 12, 2011
                        • 0 Attachment
                          --- 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 12 of 18 , Jun 12, 2011
                          • 0 Attachment
                            --- 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 13 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 14 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 15 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 16 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 17 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.