hmm this is supposed to warn about conflicts but only if the versions differ

right, forgot to compare versions 😛

just published [email protected], wasn’t sure if I published the externs inference fix from yesterday already

https://github.com/JulianBirch/cljs-ajax/issues/197#issuecomment-337564344

sometimes I just found warnings in existing projects,

is shadow-cljs more strict to libraries?

alrighty. Is there a way watch a :release? I’m trying to debug keybindings stuff in a windows virtual machine. loading the page across this weird not-really-a-network-boundary is incredibly slow, 2.41 minutes to load the page with 700 requests. it would be faster to advance or simple compile and then have a much smaller bundle

@jiyinyiyong thats based on the clojurescript version you are using. shadow-cljs always uses the latest while other tools might use older versions. uri? was added recently.

@mhuebert haha doh, there is no watch for release no.

I had a “compact” mode once, which was :none but one file

removed that since it didnt seem to make sense 😛

I want to reduce the number of requests though

alright. i can just run releases and reload

I’ll probably bundle all packages together at one point

so that “react” is one request not many

but nothing available now

@jiyinyiyong curious what made you report that error to cljs-ajax?

am encountering a bug where sometimes my Keypress fork (which is referenced as a github commit hash) is being overwritten by the one from npm

however, after reproducing once, I can’t again

I think I will rename my fork so that it will never attempt to download from npm

one thing that might be happening is a conflict

there is that conflict where it thinks it has a conflict, but actually the versions are the same

because of source-paths

no I mean npm conflict

shadow-cljs will ONLY look at node_modules/thing

but sometimes npm installed things like node_module/thing-a/node_modules/thing-b

because a node_modules/thing-bg already exists, just with a different version

or npm handles installed from git differently? never did that before

somehow the wrong files are being written to node_modules/thing during install

I have no idea how to resolve npm conflicts

i had a watch run, all good, correct files. when i made a release, the wrong version overwrote it

hmm? I don’t ever touch node_modules

during the installing npm deps?

or that’s cljs handling that

ah ok you call npm-deps

I added a fix this morning that does not attempt to install anything thats already listen in package.json

maybe thats whats happening

npm-deps just blindly called npm install

but this was part of the 2.0.23 release

are you using that?

the time when this happened was actually the first build after i had run yarn upgrade shadow-cljs

hmm when I run yarn I do not get the github version?

[:deps-version-conflict "github:braintripping/Keypress#1442b0a" "braintripping/Keypress#1442b0a" #object[java.net.URL 0x5f9b22c1 "jar:file:/Users/zilence/.m2/repository/lark/tools/0.1.14/tools-0.1.14.jar!/deps.cljs"]]

this is when I run shadow-cljs npm-deps

is npm run the same as yarn run

do you use npm or yarn?

I think you are supposed to use npx over npm run

well i was using yarn, but since cljs is always using npm, i think i should be consistent

nono I just didn’t add yarn support yet

I do use yarn as well

[zilence@zpro ~/.m2/repository/lark/tools/0.1.14]$ cat deps.cljs
{:npm-deps {"keypress.js" "braintripping/Keypress#1442b0a"
            "codemirror"  "^5.30.0"}
 :externs  ["externs/lark.commands.ext.js"]}

I think thats missing the github:?

hm didn’t think it was necessary

but i’ll add that

no idea?

more explicit, better anyway

its just complaining about it because the version in package.json is different from the one in deps.cljs

it will then attmpt to install that

no wait .. I don’t understand my own code

it will SKIP installing

I have no idea how npm works …

I just did what CLJS does

in any case, I’ve changed this to a scoped npm dep, so it cannot ever default to fetching something from npm

probably a good idea yeah

so right now you can run dev.maria.cloud and www.maria.cloud and compare shadow vs. old build

the shadow build is a bit smaller and loads slightly faster on my machine, despite being many x more files (so i guess http2 is working!)

while actually editing, the dev version is much faster but thats because i fixed some perf bugs

yeah h2 is perfect for this

how come https://dev.maria.cloud/ already does all the init stuff?

it doesn’t appear to use the compiler?

oh wait nvm. thats also the live frame

1.3mb shadow vs 1.5mb

seems like a win 😉

I’ll see if I can find something that takes too long on slower devices

4x cpu throttle perf seems much better

takes 19sec for page to load

shadow version 9sec

that is a big diff.

obviously this is still a massive bundle but no escaping that for now

I can improve that part so it doesn’t render block

1st time :release is about 1 minute, subsequents ~12sec, that is all 3 builds. that is __way____ faster than before.

neat

plus it’s doing all this bootstrap stuff on top.

live reloading works better than before, that is also because my cljs-live goog.require hacks did not play well with figwheel

hehe yeah I can imagine

https://github.com/braintripping/re-view/blob/master/re_view/src/re_view/render_loop.cljs#L73

that tag is incorrect, ^boolean not ^:boolean

just checking the render profile and it seems like re_view.render_loop.render_loop is actually called more than once per rAf

no idea if its supposed to

anyways, looks nice. don’t think I can do much more tuning of the bootstrap stuff

a bit maybe but not much

@thheller oh, thanks, it appears I’ve made that ^boolean mistake a number of times in other code bases too

i don’t think it should be called more than once per rAf

woho .. I fixed the conditional requires react and apparently others do

#{module$node_modules$object_assign$index
  module$node_modules$react$cjs$react_development shadow.js
  module$node_modules$fbjs$lib$invariant
  module$node_modules$fbjs$lib$emptyObject
  module$node_modules$prop_types$lib$ReactPropTypesSecret
  module$node_modules$fbjs$lib$emptyFunction
  module$node_modules$prop_types$checkPropTypes
  module$node_modules$fbjs$lib$warning}

#{module$node_modules$object_assign$index
  module$node_modules$react$cjs$react_production_min shadow.js
  module$node_modules$fbjs$lib$invariant
  module$node_modules$fbjs$lib$emptyObject
  module$node_modules$fbjs$lib$emptyFunction}

dev vs production

that looks way better

should make packages a bit smaller and doesn’t require the custom react :resolve anymore

I like

@mhuebert [email protected] should speed up your builds considerably since babel transformed files are now properly cached