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

JSLint options saved as a cookie.

Expand Messages
  • pauanyu
    Previously, the cookie JSLint used to store the settings was a rather long-lived cookie. Recently, this was changed so the cookie would expire at the end of
    Message 1 of 11 , Aug 19 11:36 PM
    • 0 Attachment
      Previously, the cookie JSLint used to store the settings was a rather long-lived cookie. Recently, this was changed so the cookie would expire at the end of the session.

      It is very inconveniencing to have to reset the options every time I close and reopen my browser. In fact, because the default settings are extremely lenient, I have made mistakes where I thought my file was valid, when in fact I had merely forgotten to check the settings.

      I kindly request that the cookie's lifetime be extended to at least 1 week.
    • Arthur Blake
      IMHO, even nicer and more useful than using the cookie, is simply specifying the jslintoptions at the top of your JS file! ... That way you can customize the
      Message 2 of 11 , Aug 20 8:46 AM
      • 0 Attachment
        IMHO, even nicer and more useful than using the cookie, is simply specifying
        the jslintoptions at the top of your JS file!

        Options can also be specified within a script with a /*jslint */ comment:
        >
        > /*jslint nomen: true, debug: true,
        > evil: false, onevar: true */
        >
        > An option specification starts with /*jslint. Notice that there is no
        > space before the j. The specification contains a sequence of name value
        > pairs, where the names are JSLint options, and the values are true or
        > false. The indent option <http://www.jslint.com/lint.html#options> can
        > take a number. A /*jslint */ comment takes precedence over the option
        > object.
        >

        That way you can customize the setting on a per file basis if needed too!

        On Thu, Aug 20, 2009 at 2:36 AM, pauanyu <pcxunlimited@...> wrote:

        >
        >
        > Previously, the cookie JSLint used to store the settings was a rather
        > long-lived cookie. Recently, this was changed so the cookie would expire at
        > the end of the session.
        >
        > It is very inconveniencing to have to reset the options every time I close
        > and reopen my browser. In fact, because the default settings are extremely
        > lenient, I have made mistakes where I thought my file was valid, when in
        > fact I had merely forgotten to check the settings.
        >
        > I kindly request that the cookie's lifetime be extended to at least 1 week.
        >
        >
        >


        [Non-text portions of this message have been removed]
      • pauanyu
        ... Why would I want to add this to top of every one of my dozens and dozens of JavaScript, CSS, and HTML files: /*jslint white: true, onevar: true, browser:
        Message 3 of 11 , Aug 20 6:06 PM
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:
          >
          > IMHO, even nicer and more useful than using the cookie, is simply specifying
          > the jslintoptions at the top of your JS file!
          >
          > That way you can customize the setting on a per file basis if needed too!
          >

          Why would I want to add this to top of every one of my dozens and dozens of JavaScript, CSS, and HTML files:

          /*jslint white: true, onevar: true, browser: true, undef: true, nomen: true, eqeqeq: true, plusplus: true, bitwise: true, regexp: true, strict: true, newcap: true, immed: true */

          ?

          As for specifying options per-file.. I have absolutely no need for that. I always write my code as cleanly as possible.
        • Arthur Blake
          Just expressing my humble opinion... another few good reasons: 1. your code can be used in other JSLint environments (instead of just the web front end) and be
          Message 4 of 11 , Aug 21 7:22 AM
          • 0 Attachment
            Just expressing my humble opinion... another few good reasons:
            1. your code can be used in other JSLint environments (instead of just the
            web front end) and be validated consistently. For example, build tools,
            like jslint4java.
            2. If you have one or two modules that just have to use eval, you can turn
            on the evil flag (or any other flag), yet turn it off for all the other
            files. That way you don't have to remember to manually change the setting.
            3. Even if it's dozens and dozens of files, you can gradually add the header
            to each file as you touch them, that's what I'm doing with my hundreds of JS
            files.

            On Thu, Aug 20, 2009 at 9:06 PM, pauanyu <pcxunlimited@...> wrote:

            >
            >
            > --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Arthur
            > Blake <arthur.blake@...> wrote:
            > >
            > > IMHO, even nicer and more useful than using the cookie, is simply
            > specifying
            > > the jslintoptions at the top of your JS file!
            > >
            > > That way you can customize the setting on a per file basis if needed too!
            > >
            >
            > Why would I want to add this to top of every one of my dozens and dozens of
            > JavaScript, CSS, and HTML files:
            >
            > /*jslint white: true, onevar: true, browser: true, undef: true, nomen:
            > true, eqeqeq: true, plusplus: true, bitwise: true, regexp: true, strict:
            > true, newcap: true, immed: true */
            >
            > ?
            >
            > As for specifying options per-file.. I have absolutely no need for that. I
            > always write my code as cleanly as possible.
            >
            >
            >


            [Non-text portions of this message have been removed]
          • Arthur Blake
            Oh, and one other good reason: The comment serves as a reminder that the file should really be checked via jslint whenever it is modified (getting other
            Message 5 of 11 , Aug 21 7:24 AM
            • 0 Attachment
              Oh, and one other good reason: The comment serves as a reminder that the
              file should really be checked via jslint whenever it is modified (getting
              other developers that work on the same code base to validate their code is
              sometimes like pulling teeth.)

              On Fri, Aug 21, 2009 at 10:22 AM, Arthur Blake <arthur.blake@...>wrote:

              > Just expressing my humble opinion... another few good reasons:
              > 1. your code can be used in other JSLint environments (instead of just the
              > web front end) and be validated consistently. For example, build tools,
              > like jslint4java.
              > 2. If you have one or two modules that just have to use eval, you can turn
              > on the evil flag (or any other flag), yet turn it off for all the other
              > files. That way you don't have to remember to manually change the setting.
              > 3. Even if it's dozens and dozens of files, you can gradually add the
              > header to each file as you touch them, that's what I'm doing with my
              > hundreds of JS files.
              >
              > On Thu, Aug 20, 2009 at 9:06 PM, pauanyu <pcxunlimited@...> wrote:
              >
              >>
              >>
              >> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Arthur
              >> Blake <arthur.blake@...> wrote:
              >> >
              >> > IMHO, even nicer and more useful than using the cookie, is simply
              >> specifying
              >> > the jslintoptions at the top of your JS file!
              >> >
              >> > That way you can customize the setting on a per file basis if needed
              >> too!
              >> >
              >>
              >> Why would I want to add this to top of every one of my dozens and dozens
              >> of JavaScript, CSS, and HTML files:
              >>
              >> /*jslint white: true, onevar: true, browser: true, undef: true, nomen:
              >> true, eqeqeq: true, plusplus: true, bitwise: true, regexp: true, strict:
              >> true, newcap: true, immed: true */
              >>
              >> ?
              >>
              >> As for specifying options per-file.. I have absolutely no need for that. I
              >> always write my code as cleanly as possible.
              >>
              >>
              >>
              >
              >


              [Non-text portions of this message have been removed]
            • Dominic Mitchell
              ... Ah but that s why you need to integrate it into your build system. That s why I wrote jslint4java. If you commit bad JavaScript then you break the build.
              Message 6 of 11 , Aug 21 8:26 AM
              • 0 Attachment
                On Fri, Aug 21, 2009 at 3:24 PM, Arthur Blake <arthur.blake@...>wrote:

                > Oh, and one other good reason: The comment serves as a reminder that the
                > file should really be checked via jslint whenever it is modified (getting
                > other developers that work on the same code base to validate their code is
                > sometimes like pulling teeth.)
                >

                Ah but that's why you need to integrate it into your build system. That's
                why I wrote jslint4java. If you commit bad JavaScript then you break the
                build. And the axe-wielding project-manager comes a-knocking. :)

                -Dom


                [Non-text portions of this message have been removed]
              • pauanyu
                ... Fair enough, but your comments don t really apply to me, so I am still kindly asking for a longer-length cookie.
                Message 7 of 11 , Aug 21 12:06 PM
                • 0 Attachment
                  --- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:
                  >
                  > Just expressing my humble opinion... another few good reasons:
                  > 1. your code can be used in other JSLint environments (instead of just the
                  > web front end) and be validated consistently. For example, build tools,
                  > like jslint4java.
                  > 2. If you have one or two modules that just have to use eval, you can turn
                  > on the evil flag (or any other flag), yet turn it off for all the other
                  > files. That way you don't have to remember to manually change the setting.
                  > 3. Even if it's dozens and dozens of files, you can gradually add the header
                  > to each file as you touch them, that's what I'm doing with my hundreds of JS
                  > files.
                  >

                  Fair enough, but your comments don't really apply to me, so I am still kindly asking for a longer-length cookie.
                • altearius
                  I am also in favor of returning the previous functionality of the long-term cookie. Maintaining a /*jslint*/ block at the top of every JavaScript file that I
                  Message 8 of 11 , Aug 21 4:18 PM
                  • 0 Attachment
                    I am also in favor of returning the previous functionality of the long-term cookie.

                    Maintaining a /*jslint*/ block at the top of every JavaScript file that I am interested in is tedious. There is a significant maintenance burden associated with adding this block to all currently existing files. Moreover, since I started using JSLint, the list of possible options for the /*jslint*/ block has seen several new additions. I see no reason to suspect that the current list of options will remain unchanged forever. If I want my JavaScript files to be validated against new additions in the future, I would then need to remember to update the /*jslint*/ block, or I would need to remember to check the checkbox. It's too easy to forget something like that. Such a mistake would feel similar to forgetting to use hasOwnProperty, or forgetting to declare a variable with var before using it: it's the kind of mistake that JSLint could be helping us to prevent.

                    Also, having a /*jslint*/ block at the top of each file opens the door to another class of errors. I would never copy and paste from one file into another, but my coworkers certainly will. Imagine that I have a file that requires the use of eval, and my /*jslint*/ block says so. If EVERY JavaScript file is now required to use a /*jslint*/ block to validate through JSLint, I can bet that I'll start seeing that /*jslint evil: true */ block start propagating around. Yes, it's really a training issue, but copy-paste coders are an awfully persistent problem. If they are faced with either manually checking these checkboxes, or copy-pasting a /*jslint*/ block from somewhere else, they're going to choose the later (actually, they will first choose to do nothing, at which point I will come berate them for not validating their JavaScript with JSLint).

                    Finally, there's that "JSLint will hurt your feelings." warning. When I go to www.jslint.com, paste some code into the big code-accepting text box, I notice that none of the checkboxes are checked. So I go to check one, and poof, the "hurt feelings" warning vanishes, and all those checkboxes jump up the screen. It is disorienting and confusing: not only did my click not make it to the checkbox I was aiming for, but also the checkbox has moved about an inch up from where it was. I am not here to play whack-a-mole! ;)

                    - Chris


                    --- In jslint_com@yahoogroups.com, Arthur Blake <arthur.blake@...> wrote:
                    >
                    > IMHO, even nicer and more useful than using the cookie, is simply specifying
                    > the jslintoptions at the top of your JS file!
                    >
                    > Options can also be specified within a script with a /*jslint */ comment:
                    > >
                    > > /*jslint nomen: true, debug: true,
                    > > evil: false, onevar: true */
                    > >
                    > > An option specification starts with /*jslint. Notice that there is no
                    > > space before the j. The specification contains a sequence of name value
                    > > pairs, where the names are JSLint options, and the values are true or
                    > > false. The indent option <http://www.jslint.com/lint.html#options> can
                    > > take a number. A /*jslint */ comment takes precedence over the option
                    > > object.
                    > >
                    >
                    > That way you can customize the setting on a per file basis if needed too!
                    >
                    > On Thu, Aug 20, 2009 at 2:36 AM, pauanyu <pcxunlimited@...> wrote:
                    >
                    > >
                    > >
                    > > Previously, the cookie JSLint used to store the settings was a rather
                    > > long-lived cookie. Recently, this was changed so the cookie would expire at
                    > > the end of the session.
                    > >
                    > > It is very inconveniencing to have to reset the options every time I close
                    > > and reopen my browser. In fact, because the default settings are extremely
                    > > lenient, I have made mistakes where I thought my file was valid, when in
                    > > fact I had merely forgotten to check the settings.
                    > >
                    > > I kindly request that the cookie's lifetime be extended to at least 1 week.
                    > >
                    > >
                    > >
                    >
                    >
                    > [Non-text portions of this message have been removed]
                    >
                  • pauanyu
                    ... It appears that cookies are now saved for ~12 days. Thanks, Douglas!
                    Message 9 of 11 , Aug 21 11:20 PM
                    • 0 Attachment
                      --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
                      >
                      > Previously, the cookie JSLint used to store the settings was a rather long-lived cookie. Recently, this was changed so the cookie would expire at the end of the session.
                      >
                      > It is very inconveniencing to have to reset the options every time I close and reopen my browser. In fact, because the default settings are extremely lenient, I have made mistakes where I thought my file was valid, when in fact I had merely forgotten to check the settings.
                      >
                      > I kindly request that the cookie's lifetime be extended to at least 1 week.
                      >

                      It appears that cookies are now saved for ~12 days. Thanks, Douglas!
                    • Jeremy Vinding
                      ... I, personally, do maintain a /*jslint*/ block at the top of every one of my many dozens of files... Thanks to tools like perl, I have not found it
                      Message 10 of 11 , Aug 26 8:39 AM
                      • 0 Attachment
                        > Maintaining a /*jslint*/ block at the top of every JavaScript file
                        > that I am interested in is tedious. There is a significant
                        > maintenance burden associated with adding this block to all
                        > currently existing files. Moreover, since I started using JSLint,
                        > the list of possible options for the /*jslint*/ block has seen
                        > several new additions. I see no reason to suspect that the current
                        > list of options will remain unchanged forever. If I want my
                        > JavaScript files to be validated against new additions in the
                        > future, I would then need to remember to update the /*jslint*/
                        > block, or I would need to remember to check the checkbox. It's too
                        > easy to forget something like that. Such a mistake would feel
                        > similar to forgetting to use hasOwnProperty, or forgetting to
                        > declare a variable with var before using it: it's the kind of
                        > mistake that JSLint could be helping us to prevent.
                        >
                        >
                        I, personally, do maintain a /*jslint*/ block at the top of every one
                        of my many dozens of files... Thanks to tools like perl, I have not
                        found it difficult to keep them up to date at all. Of course, I never
                        actually use the website, I run jslint through JavaScriptCore directly
                        from my editor, and again with rhino as a SVN pre-commit hook, so
                        there are no checkboxes for me.

                        > Also, having a /*jslint*/ block at the top of each file opens the
                        > door to another class of errors. I would never copy and paste from
                        > one file into another, but my coworkers certainly will. Imagine that
                        > I have a file that requires the use of eval, and my /*jslint*/ block
                        > says so. If EVERY JavaScript file is now required to use a /
                        > *jslint*/ block to validate through JSLint, I can bet that I'll
                        > start seeing that /*jslint evil: true */ block start propagating
                        > around. Yes, it's really a training issue, but copy-paste coders are
                        > an awfully persistent problem. If they are faced with either
                        > manually checking these checkboxes, or copy-pasting a /*jslint*/
                        > block from somewhere else, they're going to choose the later
                        > (actually, they will first choose to do nothing, at which point I
                        > will come berate them for not validating their JavaScript with
                        > JSLint).
                        >

                        for cases like this I use the same /*jslint*/ block at the top of the
                        file as I do for every other file, then I enable the evilness just for
                        the line that needs it, eg:

                        /*jslint evil:true*/
                        data = (new Function( "return " + data ))();
                        /*jslint evil:false*/


                        --jjv
                      • Arthur Blake
                        Nice technique! I wasn t aware that was possible. Thanks! ... [Non-text portions of this message have been removed]
                        Message 11 of 11 , Aug 26 9:22 AM
                        • 0 Attachment
                          Nice technique! I wasn't aware that was possible. Thanks!

                          On Wed, Aug 26, 2009 at 11:39 AM, Jeremy Vinding <yui@...>wrote:

                          > for cases like this I use the same /*jslint*/ block at the top of the
                          > file as I do for every other file, then I enable the evilness just for
                          > the line that needs it, eg:
                          >
                          > /*jslint evil:true*/
                          > data = (new Function( "return " + data ))();
                          > /*jslint evil:false*/
                          >
                          > --jjv
                          >
                          >
                          >


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