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

ANN: JSLint Reporter (Node.js wrapper)

Expand Messages
  • Frederik Dohr
    Here s yet another[1] JSLint wrapper for command-line enthusiasts. Since my Python wrapper[2] for JSLint always seemed overly complex, I ve created a
    Message 1 of 7 , Jan 26, 2011
    • 0 Attachment
      Here's yet another[1] JSLint wrapper for command-line enthusiasts.

      Since my Python wrapper[2] for JSLint always seemed overly complex, I've
      created a pure-JavaScript wrapper using Node.js:
      https://github.com/FND/jslint-reporter

      I've attempted to keep it as simple as possible; the makefile adds only
      a single line to JSLint (`make jslint`) for Node.js-compatibility
      ("module.exports.JSLINT = JSLINT;") - the rest (i.e. wrapper.js) is just
      some glue to pass data to JSLINT.

      The output is in standard error format (<file>:<line>:<char>:<error>),
      so it can easily be used from within editors like Vim et al.

      Since folks here are very good at uncovering unexpected behavior, I'd
      greatly appreciate some feedback.


      -- F.


      [1]
      http://tech.groups.yahoo.com/group/jslint_com/database?method=reportRows&tbl=1
      [2] https://github.com/FND/jslint-cli
    • Merlin
      ... Rather than using fulljslint.js, why not use the minified version from http://www.JSLint.com/jslint.js ? Harry.
      Message 2 of 7 , Jan 26, 2011
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Frederik Dohr <fdg001@...> wrote:
        > Here's yet another[1] JSLint wrapper for command-line enthusiasts.

        Rather than using fulljslint.js, why not use the minified version from

        http://www.JSLint.com/jslint.js ?

        Harry.
      • Frederik Dohr
        ... Well, given that HTTP overhead is not a concern in this context, I don t see any benefit in using the minified version. Having said that, it s probably
        Message 3 of 7 , Jan 26, 2011
        • 0 Attachment
          > Rather than using fulljslint.js, why not use the minified version
          > from http://www.JSLint.com/jslint.js ?

          Well, given that HTTP overhead is not a concern in this context, I don't
          see any benefit in using the minified version.

          Having said that, it's probably best to use jslint.com/fulljslint.js
          rather than GitHub, as that seems like the canonical URL.


          -- F.
        • Merlin
          ... It would be good if it were possible to set options off with something like: node wrapper.js --goodparts --nomen=false example.js . That would obviate the
          Message 4 of 7 , Jan 27, 2011
          • 0 Attachment
            --- In jslint_com@yahoogroups.com, Frederik Dohr <fdg001@...> wrote:
            >
            > Here's yet another[1] JSLint wrapper for command-line enthusiasts.

            > Since folks here are very good at uncovering unexpected behavior, I'd
            > greatly appreciate some feedback.

            It would be good if it were possible to set options off with something like:

            node wrapper.js --goodparts --nomen=false example.js .

            That would obviate the need to list all of the good options bar one.

            Also something like:

            node wrapper.js --predef "window, ..." test.js

            to be able to set predefined items.

            Harry.
          • Frederik Dohr
            ... That seems like a reasonable thing to do. It ll require a slightly different approach to parsing command-line arguments though - I ll look into that next
            Message 5 of 7 , Jan 28, 2011
            • 0 Attachment
              > It would be good if it were possible to set options off with
              > something like:
              > node wrapper.js --goodparts --nomen=false example.js .
              > That would obviate the need to list all of the good options bar one.

              That seems like a reasonable thing to do. It'll require a slightly
              different approach to parsing command-line arguments though - I'll look
              into that next week. (While there are plenty of option parsers for
              Node.js, I was trying to avoid external dependencies.)

              > Also something like:
              > node wrapper.js --predef "window, ..." test.js
              > to be able to set predefined items.

              Indeed, predef is currently unsupported - I suspect this will fall out
              of the refactoring above.

              FWIW, I'm also planning to add an --upgrade option to grab the latest
              version of fulljslint.js, thus rendering the makefile obsolete (cf.
              external dependencies).


              -- F.
            • Merlin
              ... The conventions on Unix for negative options have always been a bit quaint. However, I would guess that you could do something like: node wrapper.js
              Message 6 of 7 , Jan 28, 2011
              • 0 Attachment
                --- In jslint_com@yahoogroups.com, Frederik Dohr <fdg001@...> wrote:
                >
                > > It would be good if it were possible to set options off with
                > > something like:
                > > node wrapper.js --goodparts --nomen=false example.js .
                > > That would obviate the need to list all of the good options bar one.
                >
                > That seems like a reasonable thing to do. It'll require a slightly
                > different approach to parsing command-line arguments though - I'll look
                > into that next week. (While there are plenty of option parsers for
                > Node.js, I was trying to avoid external dependencies.)

                The conventions on Unix for "negative" options have always been a bit quaint.
                However, I would guess that you could do something like:

                node wrapper.js --goodparts -nomen example.js (note single minus sign on nomen)

                fairly easily, without having to use an external parser. It would seem odd to use +nomen
                to turn the option off.

                >
                > > Also something like:
                > > node wrapper.js --predef "window, ..." test.js
                > > to be able to set predefined items.
                >
                > Indeed, predef is currently unsupported - I suspect this will fall out
                > of the refactoring above.
                >
                > FWIW, I'm also planning to add an --upgrade option to grab the latest
                > version of fulljslint.js, thus rendering the makefile obsolete (cf.
                > external dependencies).

                That is an excellent idea. Ideally you should limit how often you upgrade to save load on the servers. In my Widget Tester Widget, I pull the JSLint file no more than once a day.

                Harry.
              • Frederik Dohr
                I ve just added an --upgrade option, so there s no need for the makefile anymore; simply run `node wrapper.js --upgrade` to download the latest version of
                Message 7 of 7 , Feb 2, 2011
                • 0 Attachment
                  I've just added an --upgrade option, so there's no need for the makefile
                  anymore; simply run `node wrapper.js --upgrade` to download the latest
                  version of JSLint:
                  https://github.com/FND/jslint-reporter

                  I'll revisit option parsing in the next few days.

                  > The conventions on Unix for "negative" options have always been a
                  > bit quaint. However, I would guess that you could do something like:
                  > node wrapper.js --goodparts -nomen example.js (note single minus sign
                  > on nomen)

                  I don't like the potential confusion of single vs. double dashes.
                  Instead, I'll probably go with "--no-<option>" or "--<option>=false"
                  (the latter would be consistent with something like --predef="...").

                  > That is an excellent idea. Ideally you should limit how often you
                  > upgrade to save load on the servers.

                  I expect --upgrade to be a manual operation, performed by the user every
                  couple of days/weeks.

                  > Do please consider the security aspects. [...] It *is* possible to
                  > run JavaScript code sandboxed in Node. Maybe you should consider
                  > that, instead of the module approach.

                  While I understand and appreciate your concern, I'm not too worried
                  about this myself. However, I would be very happy to accept patches.


                  -- F.
                Your message has been successfully submitted and would be delivered to recipients shortly.