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

Tolerate

Expand Messages
  • Douglas Crockford
    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,
    Message 1 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:

      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.
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 of 18 , Sep 2 11:32 PM
                              • 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 15 of 18 , Sep 5 10:15 AM
                                • 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 16 of 18 , Sep 5 8:45 PM
                                  • 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 17 of 18 , Sep 6 11:41 AM
                                    • 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 18 of 18 , Sep 6 12:30 PM
                                      • 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.