[
https://issues.apache.org/jira/browse/THRIFT-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305942#comment-14305942
]
Andrew de Andrade commented on THRIFT-2738:
-------------------------------------------
If we were to only use one, 100% go with eslint. It's way better than all the
other linters out there. The reason for using both is that jscs has more
whitespace rules than eslint. However, eslint is catching up on the whitespace
rules that jscs has.
The rules we used in lint-trap were designed isomorphic code in the npm
ecosystem. i.e. any code that needs to work in both nodejs and in the browser
via browserify.
Some of the rules would not work with the code in lib/js. For example, the
lib/js stuff relies on globals on the {{window}} object, which is something
that we expressly forbid in rules we came up with. My personal opinion is that
the code in lib/js and the generator for lib/js should be deprecated in favor
of a single codebase in lib/nodejs. From that single codebase, we can use
browserify to generate a "standalone" version of thrift (see the standalone
documentation in the browserify readme
https://github.com/substack/node-browserify ). The only additional work that
would be required would be to take the generated nodejs client library and put
it in a wrapper that exposes the same globals the client library currently
exposes (since the nodejs library doesn't pollute the global namespace at all.)
I can't think of a solid reason, except backwards compatibility (API) for
maintaining both a lib/js and lib/nodejs. With a little work and
reorganization, everything common between the browser and nodejs should be
shareable. The browser.js file in THRIFT-2976 is my first attempt at a file
that could be browserified with the standalone option.
If I were to design the lib/js generator from scratch, I would have the
generator basically start with the nodejs generated code and you would give it
the type(xhr or websockets), transport, protocol, host, port, ssl and minify
flags as options and I'd generate the whole thing as one file people can drop
into their page and I'd only expose a client on the global namespace.
Specifying the transport and protocol at the command line during generation
means that you'd only bundle the transport and protocol you need in the final
javascript file. The big change API wise for current users of the lib/js
approach is that all callbacks will be node style callbacks where the first
callback arg is a maybe error.
Here are the eslint rules we use in lint-trap:
https://github.com/uber/lint-trap/blob/master/rc/.eslintrc
> JS coding standards
> -------------------
>
> Key: THRIFT-2738
> URL: https://issues.apache.org/jira/browse/THRIFT-2738
> Project: Thrift
> Issue Type: Sub-task
> Components: JavaScript - Library, Node.js - Library
> Reporter: Konrad Grochowski
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
