thanks @mfikes, I notice that there are a couple of PowerShell scripts, I won’t change those, but I can look at getting Windows coverage via git bash for current sh/bash shell scripts.

Is it possible to turn on *warn-on-infer* on a project level rather then per file? I’m in the process of adapting a large project for advanced compilation, having externs inference working for entire project would be much more helpful.

I think it could be possible to hook into analyzer and selectively set *warn-on-infer* for project namespaces

shadow-cljs does this with :infer-externs :auto but CLJS doesn't support that by default currently

@thheller is it possible to hook this code into cljs compiler?

the shadow-cljs code no. doing the same would be easy though.

ok, looking into shadow’s sources then, thanks

perhaps we could get this into figwheel as well

https://github.com/thheller/shadow-cljs/blob/815ce0dc8caab05fedbec5d182b92a1c994b8308/src/main/shadow/build/compiler.clj#L435

thats basically the logic. if file is available (ie. not source from a .jar) then assoc :infer-warning true

probably a similar two line patch in CLJS proper

cool, thanks!

@thheller I guess shadow also typehints dotted expressions with ^js to avoid manual hinting? Where is it located in the code?

uhm yeah it does a bunch of stuff regarding externs inference overall to reduce some of the "noise"

@thheller Is it a lot of code in shadow? I’m thinking if this would be possible to have on top on cljs compiler as well

well it is implemented entirely differently so you won't get that into CLJS

I mean I’d like to have this in a project, not in compiler itself, but as a part of build pipeline.

it is part of the compiler. I decided to simplify and use "untyped" externs inference

https://code.thheller.com/blog/shadow-cljs/2017/11/06/improved-externs-inference.html

so the externs inference in the compiler otherwise is a bit more complicated since it has to propagate type hints more thoroughly

all the code I have for this in shadow-cljs does not do this so it wouldn't work in combination with the stuff in CLJS

but really there are only a couple of points in the compiler that need to be "fixed"

just don't use shadow-cljs as a reference and dig into the actual code in the analyzer a bit

I was just too lazy and wanted something a bit simpler

other reason for type hinting driven externs inference is for getting that info from Closure libs into ClojureScript

esp. primitive info - boolean, string, etc.

relatively minor - but would eliminate another case of manual hinting

yeah my concern was more on the npm integration stuff where type hints won't be available anytime soon

right

to be clear externs inference is intended to be generic machinery

one use case is foreign libs

the other is deriving information about Closure libs

docstrings, types, etc.

It’s super easy to develop with SIMPLE optimizations, but so hard to switch to ADVANCED afterwards 😞

hmm not really. externs inference is already pretty good. just need to tweak a few cases where it reports false positives or things already in externs

one thing that made a big difference was importing all known properties from the closure compiler and don't warn for those

unfortunately that was in a package-protected method

https://github.com/thheller/shadow-cljs/blob/de065f237031f2e8233642c96b0030477ce2be30/src/main/com/google/javascript/jscomp/ShadowAccess.java#L30

@roman01la warn on infer on the whole project would be undesirable at this point and we're not going to do what shadow does for now

but that removed a lot of noise

I will say developing for a long time w/o advanced is asking for trouble

@dnolen I understand. I’ve hacked global inference with :warnings option set + a custom warnings handler. At least now I can see something.

we're not going to solve bad practice problems with workarounds

especially when we spent a ridiculous amount of effort making this stuff better already

well it could use a couple of "fixes" still. IIRC defrecord generates a infer warning

yeah there's minor stuff, but I haven't run into any show stoppers yet

nor heard many bad stories lately

well that might be because externs inference isn't very useful when using CLJSJS externs and people just don't enable it

doubtful

since plenty of people funnel through the webpack guide

I haven't worked on a project in over a year that doesn't use webpack in some form

I would expect that it is not uncommon to still have cljsjs/react on the classpath and still end up with its externs

but anything else you need from npm would go the webpack route and needs externs

plenty of useful trivial libs that you won't find on CLJSJS

yeah of course. still any wrapper lib that has a CLJSJS package might have externs, even if you don't actually use the lib and just use webpack to get it