reconsider using string requires for anything non-cljs/closure


I said it before in and I still think a "string" in :require should always be used for anything that is not CLJS/closure.

The string variant already works for :nodejs now, so there is no longer a difference in code.

The only difference is in the backend in how symbols are resolved. That now has a ton of special cases just because a symbol may be an alias for a npm-package. If an npm-package doesn't exist the magic symbol won't exist either. With the "react" require it would be clear that the user wanted to import a NPM package and could be warned accordingly if it wasn't installed.

This is not a great error message (manually added the extra lookup possibility)

I think this feature would be much easier for the user if we were always using a string for JS requires. It would also make the parts of the config for :foreign-libs obsolete as the :nodejs support has shown (which doesn't need it at all).

IMHO a string is a perfectly fine indicator for the analyzer to treat it differently to a symbol and makes the code a whole lot easier to reason about.

I consider string requires to be the equivalent of :import for Java classes in CLJ and we should have a definite way to tell what something refers to. In case of react we can't really tell without a whole lot of lookup logic, with "react" that is easy.

Just my 2 cents, feel free to close if you disagree.




Thomas Heller
July 14, 2017, 11:56 AM

I don't get what #|| is or what it would achieve over strings. This is strictly about separating JS "packages" from everything else, just like Clojure uses :import to separate Java Code from Clojure Code. I also never said that it has anything to do with node, but node can and will now use it. [1]

Well, I get the message. I'll stop talking about it.


David Nolen
July 14, 2017, 11:22 AM

String based require has nothing to do with Node.js. If Clojure had #|| literal to support arbitrary symbols we would use that instead.





Thomas Heller