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

Re: [jslint] Re: ANN: JSLint Reporter (Node.js wrapper)

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.