If the statements you mention here are the only quirks, then you could build (and possibly publish) your own JSLint runner for ExtendScript which filters them out, maybe by commenting or stringifying (// #targetengine or #targetengine;) to preserve line numbers, before running JSLint. Since youre not changing any of the actual source code, that would be acceptable in my book.
If the ExtendScript quirks extend into EcmaScript territory then JSLint is not the way to go.
] På vegne af John Hawkinson
Sendt: 4. februar 2011 07:13
Emne: [jslint] JSLint for not-quite-JS dialects?
variant that's used to script Adobe Creative Suite products,
like InDesign, PhotoShop, etc. It uses the .jsx file extension.
One of its quirks is that it has several "preprocesor"-style
directives that can be incldued in script files, some of which
are necessary for some scripts (e.g. "#targetengine session").
I wrote to Douglas Crockford asking for a JSLint option to
ignore such in JSLint, since otherwise JSLint produces a fatal error.
He replied saying (quoted w/ permission):
> No. JSLint is intended to improve code portability. It rejects Microsoft's
> proprietary traps, as well as Adobe's. # is likely to mean something very
> different in the next edition.
Any suggestions on where I can go from here? I don't particularly
like the idea of maintaining a private fork of JSLint for my own use
(nor a public one!). "Don't use JSLint on this code" is unpleasant.
Preprocessing my .jsx files before JSLint is similarly cumbersome.
I also would like to be able to encourage other Adobe ExtendScript
developers to use JSLint.
Are there any good solutions anyone can recommend?
By way of background, the preprocessor-extensions in ExtendScript are:
and they are documented at
on page 216 and following.
As of Edition 2011-01-28, JSLint produces:
Problem at line 29 character 2: A css file should begin with @charset 'UTF-8';
Thanks very much for any thoughts.
[Non-text portions of this message have been removed]