Closed audishos closed 5 years ago
Hi @audishos. Thanks for filing this issue!
I can't find a way to even parse dynamic imports with either the eslint parser or the esprima parser.
It looks to me like dynamic imports are still a proposal? Can you add some extra details in which environment you're using them?
It's supported via webpack https://webpack.js.org/guides/code-splitting/#dynamic-imports I'm using it in react so using babel with the plugins babel-eslint and babel-plugin-syntax-dynamic-import. babel-plugin-dynamic-import-node if using with node.
Thanks for clarifying. I'm not sure we want to support TC39 proposals, regardless of what stage they are in, until they are supported by eslint proper. However, if you can convince me that it's highly likely to change significantly, I'd be happy to mentor you creating a pull request for dynamic import support.
In the meantime, you could disable the rule with an eslint-specific comment (per line, per file), but I'm not sure if that will help you avoid parser failures like in this case.
According to the current draft, it seems like the callee node is called ImportCall
.
If you want to give this a go, you'd have to allow ImportCall
callees in method.js, line 77
I tried case "ImportCall":
to the list under "those are fine" but no dice. Is this what you meant?
Thank you for filing this issue @audishos. Let me know if the pull request by @spalger in #84 works for you and I'll make a new release sometime later this week.
Installed via github master branch and looks like the issue is resolved. Please let me know once the release is available.
Cheers!
Published!
npm notice 📦 eslint-plugin-no-unsanitized@3.0.1
Didn't this just enable arbitrary script loads? dynamic import accepts expressions, it's even more dangerous than innerHTML
in that regard, as it directly loads scripts. Perhaps it could be allowed to be called with string literals only?
Interesting point @koto, I recommend opening another issue
Yeah. That's bad.
It doesn't like dynamic imports 👎