I'm trying to use shadow with deps.edn, but I'm getting this:

Wilker-Nu:pathom-book wilkerlucio$ shadow-cljs watch book
shadow-cljs - config: /Users/wilkerlucio/Development/pathom-book/shadow-cljs.edn version: 2.1.16
shadow-cljs - starting via "clojure"
Invalid option: -Sdeps

ideas what's that about?

I'm getting it should be trying to call -Spath instead?

I've been spending a lot of time tonigh trying to find out why shadow-cljs release compiles differently on my computer vs on server. I'm useing same node and shadow-cljs versions, its the same git repo. I don't know what I could be missing, what could cause this. Because the error I get from the server I don't get on my computer, and if I copy the server compilation on to my computer, then I get the same error.

oh I think I see it now, on my computer I has shadow-cljs 2.1.6 the server has 2.1.16, guess my eyes got fooled, going to check that..

yup confirmed, there's clearly an error that is present in 2.1.16 that is not present in 2.1.6, and reading the error it doesn't look like my code is anywhere there in between

TypeError: Cannot call a class as a function
    at b.a (quill.js:1952)
    at new b (quill.js:5471)
    at b.value (quill.js:5367)
    at b.value (quill.js:6617)
    at new a (quill.js:1111)
    at a.createEditor (mixin.js:13)
    at a.componentDidMount (component.js:202)
    at a.componentDidMount (factory.js:666)
    at commitLifeCycles (react-dom.production.min.js:150)
    at c (react-dom.production.min.js:159)

@wilkerlucio -Sdeps should be available. maybe you have an older version where its not?

@hlolli they only thing I can think would be the closure compiler update

you can try shadow-cljs release build --debug to get a more usefull error maybe

@thheller yes, I gave up. It was successfully compileing, then I updated shadow, it failed, so I wanted to go back to version 2.1.6 and the failure stayed, maybe cacheing, target unclean. Don't know, but I'm ditching react-quill, useing quill straight up.

@thheller on the spot, updated clj and it's working fine 🙂

could maybe be related to :default?

maybe, as for every module require I was doing Module/default (which after reading the docs better, is avoidable), except react-quill... ok, going to have one more look at the chilren of the objects returned by importing react-quill...

:default is in a weird situation in some packages because even though they might provide examples as ES6 with default imports

is it possible to activate extra deps aliases via command line?

they sometimes publish commonjs instead

@wilkerlucio no, only per config :deps {:aliases [:alias ...]}

extra-deps does not make sense to me in a CLJS setting. maybe you have a use-case where it make sense but so far I haven't found one

I was thinking that shadow could have something like --clj-options -A:more-alias:other

in my case is more related to extra paths

yes, maybe shadow could default to :default, probably screws up backwards compatability (and not compatable with rest of cljs I assume, so bad idea)

I imagine having deploy build with regular settings, but for dev I want to add local source paths to use dev versions

also there could be situations you want to try building against different lib versions

@hlolli :default isn't in CLJS yet so I could definitely change it. problem is that the node/webpack world handles default exports differently than closure

so I'm totally unsure which way to go

I tried going the closure way but that broke way too many libs so I went with a compromise for now

@wilkerlucio ok, I'll add -A support

closure is working on a pace like javascript was in 1999... slow 🙂

specifying the default is bearable enough to wait and see how closure develops

nah the situation is just messy and supporting the mess that is on npm sometimes is not their goal

problem really is that default import/exports didn't exist before ES6

and everyone has a different interpretation about when or how to use them

so every package does something a little different

which is just messy

I think I should just adopt what webpack does

and requireing from closure, it can't differentiate that it's requireing es6 or cjs?

yes, it's very messy, all my kudos to the closure developers that are trying to make something stable

problem is that people publish converted ES6 code to npm

ie. code that was ES6 but was converted to common js by babel

closure detects those as commonjs and rewrites them accordingly

BUT that breaks how others require those

so ... mess ..

but thats part of the reason I don't use closure to process anything on npm

ah, ok I though google closure had some babel functionality behind the hood, since import seemed to be what was running

well I use closure but not their es6/cjs rewriting

if you can tell me which package fails now that worked before I can take a look

react-quill

and your require for it is?

Im swimming in a mess, just deleted target and trying again now, then I can test this require

["react-quill" :as Quill]

see .. super weird package

but [:> Quill ...] should be working?

that works in 2.1.6

not 2.1.16, didnt try in between, so I dont know where it fails, well I did try, but as I was down to 2.1.10 I realized I didnt delete target in between of downgrading shadow-cljs 🙂

deleting target directory should never be necessary

cache is smart enough to detect file changes

I had successful case of deleteing target just 5 mins ago, shadow-cljs was complaining about superfuntion or something, too strange to make sense, so it left after I tortched target.

https://unpkg.com/[email protected]/lib/index.js

module.exports = require('./component'); is what you get with :as Quill

but that also has a Quill property

facepalm haha

but none of that behaviour should have change between the versions

ok..

I can try 2.1.6 again moment

(not that I want to prove you, but to see if this is irrelevant)

Im doing the "crunch", so my short term memory and overall demenour is not crisp

I reproduced the error with 2.1.16

ok, phew, so, I reproduced the success with 2.1.6

I'll see if its the closure version

crap ...

downgrading ONLY closure fixes it 😞

it might work if you add [com.google.javascript/closure-compiler-unshaded "v20180101"] to your deps

thats the release before their big changes

I'll try to figure out whats different and see if I can do something about that

ok nice I'll try

oh wait I just tested with [com.google.javascript/closure-compiler-unshaded "v20170910"]. so maybe thats the safe option.

ok, I'm starting the first one now, let's see, try the other one if it fails

confirmed that v20180101 works

but it prints a bunch of warnings that aren't there with v20170910

yes it works, but notice a clue here, if you do [:> Quill/Quill] you get the same error as before.

Quill is the react-quill component

Quill/Quill is basically (:require ["quill" :as Quill])

since they just pass that through

and also printing the object Quill (the :as Quill) then the letter c #object[c], was b. If that could matter

ok I see

nah thats just the minifier being weird

thanks so much, here ends 11 hours struggle 😄, these kinds of issues really kill the flow and fun.

but I've been lucky for long time, it was my turn hehe

yeah these kinds of things are painfully annoying

I'd prefer if it was something I did but I guess its not 😞

easier to debug if its on my end

thats a good mindset, but yeh, it shows thats closure can sometime do non backwards compatable things.

in their defence, workings with npm deps, I give them a break on that one

no idea what to do though short of git bisect

maybe there's some logic to their changes, or this is a bug, it seemed to be the default export was the supposedly nested quill.js object. Could that be symbol bug, maybe we can give this a better try on the newest closure compiler.

no default exports in this code

v20180204 is the latest release

at least the difference seems to be that what object ["react-quill" :as Quill] becomes, differes between the compiler versions.

pretty sure there is just some extra rewriting happening that wasn't there before

the object still seems to be the same

its still a react component and stuff

the exception happens somewhere deep in Quill code

not even react

really... it seemes to me that the error message from the older version from [:> Quill/Quill] and [:> Quill] in newer compiler is exacly the same, but I can look better..

Quill/Quill is never the component

I'm logging it before trying to mount it and it look identical between the versions

my theory goes like that, that in newest closure version ["react-quill" :as Quill] is also not the component

ok, then.. my theory is wrong 🙂

exports was just my first instinct but it was wrong

bisect this commit is bad

https://github.com/google/closure-compiler/commit/6b807c063d42a463e3c32e5911c695a0976e2b67

reported here https://github.com/google/closure-compiler/issues/2822

@wilkerlucio -A:foo now supported in 2.1.17

@thheller after I updated to 2.1.17, trying to compile is generating a lot of those:

------ WARNING #1 --------------------------------------------------------------
 File: /Users/wilkerlucio/Development/third-part/fulcro/src/main/fulcro/client/primitives.cljc:608:21
--------------------------------------------------------------------------------
 605 |   (if-not (nil? x)
 606 |     #?(:clj  (or (instance? fulcro.client.impl.protocols.IReactComponent x)
 607 |                (satisfies? p/IReactComponent x))
 608 |        :cljs (true? (. x -fulcro$isComponent)))
---------------------------^----------------------------------------------------
 Cannot infer target type in expression (. x -fulcro$isComponent)
--------------------------------------------------------------------------------
 609 |     false))
 610 |
 611 | #?(:clj
 612 |    (defn react-type

I turned externs inference on by default so thats an extern inference warning

they are too many (140 in my case) the warns are poluting the UI on browser, making unusable =/

how I disable that?

hmm really so many? I should probably turn it off then

:compiler-options {:infer-externs true} was the previous default

true was the previous default? what is the default now?

:auto

with true you have to (set! *infer-externs* true) to get the warnings

most of then seem to come related to fulcro code

auto sets that for all FILES on your classpath

it will warn about all native interop where the interop value cannot be identified as js or clj

so yeah lots of interop produces lots of warnings

I'll revert it back to true ... 140 warnings is way too much

agreed, I just got back to sanity with the compiler option set to true again

its only an issue if you have libraries like fulcro as actual sources

when using a jar it won't warn about those

although at some point everything should probably be annotated properly

humm, that makes sense, I'm using a bunch of things in dev mode at this point

otherwise externs inference is never gonna catch on

not sure if @tony.kay is aware about those at this point

trouble is that those probably don't require externs but the compiler can't figure this out on its own

reverted the default in 2.1.18

33 |          (.on socket "message" on-message!)
----------------^---------------------------------------------------------------
 Cannot infer target type in expression (. socket on "message" on-message!)

guess I need to upgrade.

you probably want to typehint socket

how?

https://shadow-cljs.github.io/docs/UsersGuide.html#infer-externs

but if you didn't have issues so far you can probably either upgrade or disable via config

guess setting the default was a little too ambitious

upgraded and no warnings now

adding ^js also worked.

again I'm getting strange difference between server and my computer, same shadow-cljs and same closure versions, which I find hard to believe. It's the tab button from material-ui menu, when I click on it, the server greets me with

index.js:19 Uncaught TypeError: Cannot read property 'ease' of undefined
    at Object.left (index.js:19)
    at b.d.scrollSelectedIntoView (Tabs.js:257)
    at b.value (Tabs.js:308)
    at commitLifeCycles (react-dom.production.min.js:150)
    at b (react-dom.production.min.js:159)
    at ka (react-dom.production.min.js:170)
    at t (react-dom.production.min.js:169)
    at p (react-dom.production.min.js:168)
    at m (react-dom.production.min.js:166)
    at Object.enqueueForceUpdate (react-dom.production.min.js:110)

Hey, is there something equivalent to lein-ancient?

nah ok, not the compiler, both the source maps and main js file had the same md5sum

@hlolli is it possible that the server includes some other javascript that might cause conflicts?

google analytics or something similar maybe?

I've torched the js dir, no its still at this point completly the same, same server handler etc.

I'm starting to suspect some callback stuff, its way slower connection, the server is in iceland and im in germany

so typical js headache probably

ok I guess the md5sum differ, Im getting lost in all those terminal windows of on which computer I am

md5sum can always differ due to the naming scheme by closure

I guess :whitespace would be deterministic?

I wouldn't count on it. should rather try shadow-cljs release app --debug to get more clues about where you are at in the code

can also try shadow-cljs check app, maybe that has some clues

ok

just pause on exception in chrome and stepping through the code might help as well

Uncaught TypeError: Cannot read property 'ease' of undefined since its named ease I don't think its an externs issue

but maybe somewhere nil is passed where it shouldn't

which npm package is involved? besides react-dom?

https://unpkg.com/[email protected]/index.js

this one I guess

ok, I need coffee, it says on my computer

✗ shadow-cljs release public --debug
shadow-cljs - config: /home/hlolli/Documents/visitor/shadow-cljs.edn version: 2.1.16
...
[:public] Build completed. (1509 files, 1389 compiled, 0 warnings, 48.10s)

1509 files geez 😛

but on the server it's 1476 files, should be easy to track, I should have seen this earleir

hmm might be a good old npm non-deterministic install?

http://npm.github.io/how-npm-works-docs/npm3/non-determinism.html

yeh, geez, takes a minute for the browser to load the source maps

6,4mb

hehe I've seen bigger 😉

I could try yarn

https://yarnpkg.com/blog/2017/05/31/determinism/

package-lock.json is also a thing for npm if you have that committed

you can also try to compare the generated manifest.edn in the :output-dir

that lists all the included sources

but this scroll does this dynamic things closure is not very fond of

so it may just be that

ok, yes I should defenitely commit the lockfile, I see now why it makes sense

let's see what yarn does, maybe I commit that lockfile from yarn and switch over

🎉sanity! Yarn compiled the exact same amount of files and now I get the bug on my laptop, the same as on the server.

would have been better the other way around 😉

hehe yeh, I wonder if I was cacheing older react versions, going to give some downgrade a try

because I think yesterday I downgraded react and upgraded again

it seems to be bad codeing that this closure only receives 2 arguments out of 4 on call

_scroll2.default.left(_this.tabs, invert * nextScrollLeft);
module.exports = {
  left: make('scrollLeft'),
  top: make('scrollTop')
}
function make (prop) {
return function scroll (el, to, opts, cb) {
    if (typeof opts == 'function') cb = opts, opts = {}
var ease = opts.ease || inOutSine

did you test if the closure version makes a difference?

I downgraded from v20180101 to v20170910, I try the newest one with yarn quickly...

well, forget that comment about yarn 🙂 not a npm module

since scroll.js is just a single file you could override what it resolves to

cleaver!

the latest closure v20180204 didnt fix this, Im surprised how this worked for so long in the first place, only god knows (ergo nobody). But the idea of overriding I'll do anyway

looks fixable

just tried to make a release build, but on some cases I'm getting this weird error:

TypeError: Cannot read property 'log' of null
    at b (main.js:1638)

@thheller should I use :npm or will :file work too

:js-options {:resolve {"scroll" {:target :file
                                :require "./overrides/scroll_index.js"}}}

:file "overrides/scroll_index.js"

@wilkerlucio shadow-cljs release app --debug should make it easier to find whats null

thanks, trying

other thing that worth mention, when I delete the target and try to run shadow commands, I get this:

shadow-cljs - error ENOENT: no such file or directory, open 'target/shadow-cljs/logging.properties'

then I have to manually create the target/shadow-cljs back so it works

when does that happen?

if I delete the target folder

rm -rf target

which shadow-cljs command

any of then it seems, but I've been trying with watch

about the --debug, seems something related to logging

oh with :deps I guess?

on fulcro, that uses some logging stuff from closure

yeah, :deps is been used

fixed the release build, had to add :compiler-options {:closure-defines {goog.LOCALE "en"}}, I remembered reading this earlier here

goog.LOCALE "en" is one of the defaults?

didnt go trough this is still in the manifest and output "node_modules/scroll/index.js" after :js-options {:resolve {"scroll" {:file "overrides/scroll_index.js"}}}

hehe, must still keep the :target :file

ah, I tried with target :npm, wasn't sure in which direction the target was aiming 🙂

:npm is configured via :require and :require-min

:file is :file

but :target is necessary to select which key to look at next

yes, you could theoretically get all that data just from :require vs :file ? no pain to add target whatsoever

:file is a in a weird space right now since the classpath changes I made

but there is also :global 😉

ah, damn golbals

I prefer to be explicit and not just look at a bunch of keys

I could learn a thing or two from you on that topic

now I have these two files nested in release ... target dir

module$overrides$scroll_index.js
module$node_modules$scroll$index.js

did you clean the target dir? I don't clean anything

no, I bet that may help, let's see

nah the extra file doesn't harm anyone

would just be a leftover from a previous compile

the lookup should work though

you can check the modules$node_modules$material_ui$tabs$tabs.js or whatever that was called

if it has the correct require up top

it should but its been a while since I used :file

var _scroll = require('scroll');
var _scroll2 = _interopRequireDefault(_scroll);

what does the output file look like?

@thheller not sure what you mean by goog.LOCALE "en" is one of the defaults, defaults of what?

1 sec.. its loading the source map, takes longer than compileing 😄

@wilkerlucio https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/api.clj#L42-L45

and its the default in closure itself, so setting it to en shouldn't really make a difference?

well, it surely did here

strange

was a random attempt, I just remembered you saying something about it here, I tried and worked 😛

haha no "output" to show, deleted target, compiled again and now I can scroll like a m***fa*a

and what did you change?

this bast*rd opts = opts || {}; cured it haha, wow

this feature of patcheing/overriding the npm modules, is very very important. Going to implement this into the lumo binary bundler I made recently. Since requireing .node files needs always some patcheing, not counteing fixing bugs.

doesn't work in node though

that just delegates to require. can't influence what that does.

I mean implementing this concept, in js.

for :browser I control entirely how and what gets resolved

webpack has something similar, thats where I got the idea

yeh, nexe has this concept of monkeypatching, I was already on the path of seeing the importance of this.

this at least time from creating a fork, and aim npm modules to a github repo, which is the classical way I guess.

yeah :resolve {"scroll" {:target :npm :require "@hlolli/scroll"}} would have been the alternative

but also wouldn't have any effect in node

because of the non-advanced optimizations?

no because you don't require it. material-ui does.

so we do only require("material-ui") and whatever that does we have no control over

hm ok, never had to try stunt like that so far, editing nested dependencies in npm

works in webpack but not in node

I'm always amazed what closure does with the code

its a wonder anything works at all

https://gist.github.com/thheller/9ec47a878a2332317fe2d897c6d2cb2b

doesn't look anything like the input 😛

you can say closure is very foriging of the quality of the code it receives 🙂

no Im blameing the wrong victim here, this code is fine, mostly, just Tabs.js that was not filling in all the parameters

still need to do https://github.com/thheller/shadow-cljs/issues/173

that would have fixed the issue as well

just disable the closure processing of scroll

Im glad I was able to fix it, but the cost of time chaseing these errors probably outweigh the benefit. Sounds reasonable to do this.

exactly

hmm, i’m setting up shadow-cljs in a new blank project and getting

shadow-cljs - error ENOENT: no such file or directory, open 'target/shadow-cljs/logging.properties'

just fixed that

ok

for the next release?

yeah building now

👍:skin-tone-2:

hmm build failed

dunno why yet

fixed in [email protected] I hope

hmm, getting

npx shadow-cljs server
shadow-cljs - error $CLJS.Pg.resolve is not a function

doh!

that was the error I fixed

but I didn't recompile

2.1.20 should work

hmm,

mattpro:re-style MattPro$ npx shadow-cljs server
shadow-cljs - config: /Users/MattPro/Documents/sites2017/re-view/re-style/shadow-cljs.edn version: 2.1.20
shadow-cljs - error ENOENT: no such file or directory, open 'target/shadow-cljs/logging.properties'

I'm still seeing that too

does the path exist?

@mhuebert as a workaround, just mkdir -p target/shadow-cljs

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/npm/cli.cljs#L618 that should take care of creating it?

weird...

@thheller I'm just starting trying to create the react native app, but got an error that I didn't see before:

[:app] Configuring build.
[:app] Compiling ...
[:app] Build failure:
cannot find package.json for package react at /Users/wilkerlucio/Development/personal/multi-timer/node_modules/react/package.json
{:tag :shadow.build.npm/missing-package-json, :package-name "react", :package-json-file #object[java.io.File 0x55bcd296 "/Users/wilkerlucio/Development/personal/multi-timer/node_modules/react/package.json"]}
ExceptionInfo: cannot find package.json for package react at /Users/wilkerlucio/Development/personal/multi-timer/node_modules/react/package.json
	clojure.core/ex-info (core.clj:4739)
	clojure.core/ex-info (core.clj:4739)
	shadow.build.npm/find-package* (npm.clj:126)
	shadow.build.npm/find-package* (npm.clj:108)
	shadow.build.npm/find-package (npm.clj:137)
	shadow.build.npm/find-package (npm.clj:133)
	shadow.build.resolve/eval20329/fn--20332 (resolve.clj:210)
	clojure.lang.MultiFn.invoke (MultiFn.java:238)

you know what to do about this one?

/Users/wilkerlucio/Development/personal/multi-timer/node_modules/react does it exist?

is it empty maybe? I think that happened to me before

humm. looks like it

when in doubt rm -rf node_modules && npm install

I saw that before in another react native apps, there is something wrong with npm resolution

on the other project it works it used to work if you keep running npm install

I'm no stranger to just resetting the folder and start from scratch

also I use mostly yarn these days which seems a bit more reliable

@wilkerlucio thanks, a workaround is less important than figuring out how to get this fixed so that I don’t have to add an extra instruction to all my READMEs 🙂

agreed, but sometimes we just need to get going 🙂

@mhuebert when you kill the server, rm -rf target/shadow-cljs and start the server again. does the target/shadow-cljs folder exist at least?

its supposed to create that first and then write the logging.properties into that

@thheller just tried that here, it doesn't seem to be creating it

what the heck

hmm

tried it on windows and wsl linux

will try on mac

I'm on mac here

npx shadow-cljs stop said that there was no server running, but then afterwards it worked

oh i see, the directory is actually created when I run npx shadow-cljs stop

do you use :lein or :deps?

but npx shadow-cljs server does not create the directory

:deps

trying it for the first time

if you just create the directory it works though?

not the file, only the directory?

oh no!

I used mkdirp not mkdirp/sync ...

thats probably it

I didn't test with :deps

[email protected] ...

I'm done for the day. gn8.

g’night!