Fork me on GitHub
#cljs-dev
<
2021-10-17
>
raspasov13:10:19

I tried the 76ac6bf41300f821f052d03537edf7e86694fc6d sha, I believe those are coming from juxt/tick but I haven’t investigated deep:

[Sun Oct 17 2021 06:06:25.174]  ERROR   [TypeError: undefined is not an object (evaluating 'goog.debug.Logger.Level')]
[Sun Oct 17 2021 06:06:25.761]  ERROR   [TypeError: undefined is not an object (evaluating 'figwheel.repl.logging.set_log_level.call')]
[Sun Oct 17 2021 06:06:28.243]  ERROR   [TypeError: undefined is not an object (evaluating 'java.time.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.341]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.local_date.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.376]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.local_date_time.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.411]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.local_time.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.444]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.instant.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.461]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.zone_id.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.481]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.zone_offset.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.516]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.offset_date_time.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.533]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.offset_time.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.576]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.month.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.593]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.year.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.621]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.day_of_week.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.650]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.period.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.674]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.duration.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.712]  ERROR   [TypeError: undefined is not an object (evaluating 'java.time.temporal.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.766]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.temporal.chrono_field.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.785]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.temporal.chrono_unit.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.800]  ERROR   [TypeError: undefined is not an object (evaluating 'java.time.format.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.821]  ERROR   [TypeError: undefined is not an object (evaluating 'cljc.java_time.format.date_time_formatter.goog$module$goog$object.get')]
[Sun Oct 17 2021 06:06:28.870]  ERROR   [TypeError: undefined is not an object (evaluating 'java.time.MonthDay.prototype')]

raspasov13:10:26

@henryw374 Might have some pointers, please take a look if you’re available. Thank you!

souenzzo15:10:11

cc @U08E3BBST dirac.runtime.oops @UCFG3SDFV helins.binf.protocol.impl TL;DR: clojuresciprt will not accept the use of goog.object/get without (:require [goog.object])

henryw37409:10:47

Thanks @U050KSS8M - it was missing goog.object require. branch if you want to try it out: https://github.com/juxt/tick/tree/cljs-bump-2021-10

👌 1
raspasov09:10:06

Thank you! Will give it a shot.

Adam Helins12:10:27

Thanks! Weird it isn't complaining during tests

Adam Helins11:10:39

I'm just curious, even with the latest Shadow version, I don't see any warnings anywhere. Where does it come from?

souenzzo15:10:03

@UCFG3SDFV this is for the next release of CLJS This is not a new/breaking thing in cljs itself, but the closure library changed, and it will affect cljs. in short words: goog.object moved from the old way of define closure libraries to a new way, that is more strict.

👍 1
thheller14:10:25

it looks like those all use goog.object/get directly without having a proper :require for it. looks like that'll now break given that the local reference is missing

🚓 1
dnolen17:10:04

Yes there’s no workaround for that really - relying on it being loaded was probably always a bad idea

dnolen17:10:28

The core macros depended on that as well and we rolled it back

thheller19:10:46

@dnolen one way to make this transition smoother is treating goog.module with goog.module.declareLegacyNamespace() the old way and not going with goog.module.get. the non legacy modules are still quite rare but goog.object is pretty much used all over the place with the require often missing

dnolen19:10:02

We could special case goog.object and even put that behind flag that you have to enable to force people to stop this

dnolen19:10:29

I want to get macros/library writers off these assumptions quickly

dnolen19:10:02

Rather than supporting the legacy thing - prolonging bad patterns

thheller19:10:48

an alternative would be exposing these things in some shared place, so that its only done once and not per ns

thheller19:10:06

but I guess that gets kinda complicated tracking where and if it already registered/required

dnolen19:10:26

Yeah I don’t want to complicate what was already written nor parse for legacy namespaces

dnolen19:10:50

Special casing and then forcing users to enable the old behavior is way to put some fire into the ecosystem

borkdude19:10:55

Currently clj-kondo treats goog.* stuff as magic, as in, you don't need to require goog.object to use goog.object/get . If it helps, I could change this.

dnolen19:10:02

Yes please

dnolen19:10:13

That would help a lot

borkdude19:10:19

Same for goog.string and any other goog package?

dnolen19:10:17

Yes you cannot depend on anything that isn’t in base

dnolen19:10:48

I think you should also have a flag for the old behavior and we should try to coordinate the releases

borkdude19:10:48

OK. If there's a CLJS JIRA issue I could link to, to explain why this changed in clj-kondo, that would be great.

dnolen19:10:03

Yes let me do the legacy support thing first

dnolen19:10:30

Will make a ticket and the release notes can talk about this as well reference kondo which is quite popular

dnolen19:10:37

So this could be a combined effort

👍 1
dnolen19:10:16

Basically the important thing is that no Google namespace is safe from becoming a module

dnolen19:10:23

Not safe from legacy deprecation

dnolen19:10:30

So this is a important future proofing

thheller19:10:48

hmm but thinking about it. how are macros supposed to do this? say you write a macro that needs to emit some goog.object/set or whatever call

thheller19:10:07

the CLJS variant of the macro ns can require goog.object just fine but it'll still fail if the ns using the macro does not?

dnolen19:10:37

Macros writers just can’t depend on Google stuff being loaded that is just dead practice now

dnolen19:10:55

unchecked-set and get exist

dnolen19:10:02

For these low level cases

borkdude19:10:40

I guess macro writers can also include a .cljs namespace which takes care of this loading?

dnolen19:10:19

The bigger problem is goog.modules break global dependence always

thheller19:10:21

@borkdude its not about loading, that is guaranteed anyways. its about creating the local reference in the namespace using goog.object, which when done via macro might not exist

dnolen19:10:43

So this semantic from Clojure is toast for Google stuff

dnolen19:10:50

Not ClojureScript stuff

thheller19:10:00

but it doesn't have to be toast. we can just resolve goog.object to cljs.module$goog$object or which is then guaranteed to exist as long as something did a require (which the macro provider can ensure)

thheller19:10:24

as you just said "Basically the important thing is that no Google namespace is safe from becoming a module" so we just rule out using any goog ns from macros?

dnolen19:10:36

Already considered that just not interested

dnolen19:10:00

A side benefit is teasing apart reliance on Google namespaces

dnolen19:10:29

With old browsers fading into the past this is fine now for these low levels nses