still something not quite right with :npm-deps and :install-deps. What would be the intended behavior if :npm-deps false :install-deps true? install only upstream, or install nothing?

I thought :install-deps is gone and instead now a separate command? cljs.main --install-deps or so?

it's still there https://clojurescript.org/reference/compiler-options#install-deps , should it be marked as deprecated in the docs?

hmm no clue. maybe both still work.

@plexus install nothing

erm actually no

@plexus I would say you have to install upstream because otherwise your dependencies aren't going to work

ok, so :npm-deps false should be treated the same as :npm-deps nil?

yeah I don't think :npm-deps false-y is that meaningful anymore

the docs say it defaults to false but I believe it defaults to nil / absent so I guess that's really the same thing

fortunately the docs aren't overly specific

whereas :npm-deps {} == :npm-deps true? i.e. use the node_modules that is there

I think we should just edit it to clarify that it doesn't affect upstream deps

yeah those docs could definitely use some clarification... I'll have a look at that

I think once we allowed upstream deps

:npm-deps being a global control over that stopped being desirable

again I think the docs aren't particularly clear about the behavior so I don't think we're painted into a corner

the thing is that if false = nil and true = {}, then we can normalize :npm-deps that way, so we don't have to check for nil/boolean/map everywhere it's used

sure, that would remove unnecessary complexity from the code, happy to see that done

@dpsutton I finally got to take a look at 3620, sorry for delay that's one a bit of brain twister so I kept putting it off

no worries. i understand how things go in spurts. i am in no way demanding your time 🙂

the first question I have is whether you considered not tagging and detecting whether you effectively have an and or or

not a trick question - just wondering if you thought about it

i understand. and no i did not think about that approach

i suppose that would benefit by making this optimization more general

yeah I'm think we should do it that way

it's not as hard as it sounds I think

because and / or always look the same

let* a value which much be a simple type - and if

because passes go inside out

you don't have to do much, either you can fold in the children into the test or you can't

in the case of and you'll find the thing you can fold in the true branch

in the case of or, in the else branch

(if and# and# and#) is actually a terminal case

you can collapse it to and#

but then the parent can collapse that

and then the parent can collapse that, etc.

been a bit since i looked at it. are the ast passes a prewalk or postwalk?

pretty sure postwalk, so this would work

@dpsutton also if you're busy now that I've spent some time thinking about it I could give it a go over the weekend

but also happy to let you take it!

I’m on vacation so give it a crack.

If you have an itch to livestream or record it I think that would be amazing. Big ask though :)

not a bad idea