In ES5+ reserved words are valid property names, and should not be munged


Since ECMA-262 5ed, the property accessor syntax was changed to be an IdentifierName. IdentifierName allows for a reserved word to be used. Previously (in es3) it was a "Identifier" which excluded reserved keywords.

This means that it's valid ES5 to have a function named "delete" as long as it's part of a property. (e.g. delete() is invalid, but x.delete() is fine).

This affects interop forms like `(axios/delete)` or `(js/window.axios.delete)`.




Dominic Monroe
June 12, 2020, 8:53 PM

I’ve attached the rough patch mentioned above for feedback. I’ve only tested as far as confirming the output looks how I’d like.

Dominic Monroe
June 1, 2020, 3:54 PM

Yes. It’s a bit rough but I could share it now. I described it above in the hope of getting some feedback on whether the idea would work or not.

David Nolen
May 29, 2020, 8:05 PM

So a different patch than the one you originally submitted yes?

Dominic Monroe
May 17, 2020, 9:41 PM

I’ve been toying with a patch which will unconditionally allow reserved keywords in js-vars only by using ["reserved-identifier"]. This would generate axios[“delete”]() for (js/axios.delete), but (clj.ns/delete) would generate (clj.ns/delete$). Even when targetting es5, it’s better to munge the name. I think Cljs know which namespaces are JavaScript (e.g. npm/foreign libs), so when accessing those we would enable that instead.

As far as I can tell from reading the ES3 spec, and looking at what Babel/TypeScript produce for ES3 this is perfectly valid. It won’t affect you on ES3 unless you explicitly call a form tagged as js using a reserved word.

Your pinned fields
Click on the next to a field label to start pinning.


Dominic Monroe


Dominic Monroe