allow `import()` calls

[spalger]

Fixes #83

As @mozfreddyb pointed out, the spec seems to describe a node type of ImportCall, but all of the parsers available at http://astexplorer.net/ parse import() as a CallExpression with a callee of type Import, so I've used that type for the methods whitelist.

Hope that's alright, it works great.

[mozfreddyb]

The fact that there's a discrepancy between eslint and the spec makes me uneasy. I'd rather not half-support imports. Maybe you could make it work with ImportCall as well as a CallExpressionwith a callee typeImport`? I realize it won't be easy to test both variantes unless we find a way to supply an ast :thinking: Do you have any ideas?

[spalger]

Based on what I can tell none of the parsers out there produce an AST that resembles the spec. My personal opinion is that eslint-plugin-no-unsanitized should focus on supporting the ASTs that it will receive, from the parsers that people use, rather than being concerned with the spec.

I think once there is a parser that produces an AST which matches the spec, all that should be needed is a PR like this one with just a couple lines of changes and a test that uses that parser.

[spalger]

Sorry, while considering my answer I got distracted and forgot to answer your actual question!

Maybe you could make it work with ImportCall as well as a CallExpression with a callee type Import?

I assume that it would just take another line in that case statement, but I don't know enough about how AST generation works to create an AST that will match what future parsers will spit out. This is why I suggest worrying about parser compatibility rather than spec compatibility. Parser compatibility is what really matters to users don't you think?

[mozfreddyb]

Danke 💐

[mozfreddyb]

just published v3.0.2 on npm