Fork me on GitHub
#cljs-dev
<
2021-08-02
>
dnolen11:08:47

@mikerod it's because Google Closure Library itself started including code written in higher versions of JavaScript

dnolen11:08:59

so we have to lower these ourselves

mikerod14:08:27

@dnolen thanks, that helps explain why things at least are now looking transpiled when they weren’t before. Above though ends up being invalid JS I believe because of the “!” in the identifier. In a modern Chrome version for example (and firefox), I get Uncaught SyntaxError: Unexpected token '!' as I mentioned. It was suggested to me that perhaps removing the :language-out :es5 can fix this, which I am going to try. However, does that mean that :es5 is no longer supported then?

dnolen14:08:13

first - why we do need to bother transpiling a single Closure namespace?

dnolen14:08:20

because of debug loading

dnolen14:08:30

why do you need debug loading?

dnolen14:08:38

because of the REPL

dnolen14:08:49

what does the REPL have to do w/ production builds

dnolen14:08:53

absolutely nothing

dnolen14:08:42

this is just to clarify what is going on so you can have accurate mental model of what's necessary and the reasons

dnolen14:08:23

and from that you can infer - this probably degrades IE11 REPL driven development, but it should not eliminate IE11 as a target

dnolen14:08:54

or any compliant JS engine which follows the spec from 2001

mikerod14:08:16

Ok. I did suspect above was more of a repl-time situation. In that case, the :es5 can be only used during the production build and it sounds like things would still be ok.

dnolen14:08:29

yes - it it's not that's a bug

mikerod14:08:35

I was using it in repl + production, but we don’t really need it for the repl.

dnolen14:08:48

as a general rule just stop setting :language-out flag for dev

dnolen14:08:15

and you can stop thinking about it

dnolen14:08:28

you only need it for the advanced build because you need clarify what you need to reach

mikerod14:08:50

Ok, noted then. That’s good to know. I just started adding that config at a common level that was used in all other types of subsequent builds and never really considered if it’d have consequences at the dev-level.

mikerod14:08:05

That makes sense though.

colinkahn18:08:37

Is this a known issue?

(ns app.example)

(defprotocol IMarker)

(reify IMarker)
w/ warning when compiling:
Cannot infer target type in expression (. (. t_app$example114591 -prototype) -app$example$IMarker$)

colinkahn18:08:35

I’m using shadow-cljs but figured I’d check if it’s a core CLJS thing or not

borkdude18:08:26

Perhaps the wrong order :)

colinkahn18:08:01

Can you give an example?

borkdude18:08:22

I mean, usually it's best to test out issues without any downstream tooling, unless the issue is about the downstream tooling

colinkahn18:08:53

Ah, yes I can do that

colinkahn18:08:45

I think this should have shown the warning if there was one: clj -m cljs.main -c app.example but doesn’t indicate any issue.

borkdude18:08:13

perhaps shadow defaults to some setting which is not on by default in CLJS?

colinkahn19:08:36

looking through the complier-options nothing jumps out: https://clojurescript.org/reference/compiler-options

borkdude19:08:41

then perhaps #shadow-cljs knows

thheller19:08:59

@colinkahn which version is this with? that should have been fixed a while ago

colinkahn19:08:59

I’m on 2.11.5

colinkahn19:08:08

Sounds like I just need to upgrade

colinkahn22:08:30

Works on latest version.