Fork me on GitHub
#shadow-cljs
<
2018-08-20
>
beders06:08:00

First of all: Thanks for shadow-cljs. I'm still learning the details, but it has simplified my things a lot!

beders06:08:34

I'm not sure how to deal with error messages like this though:

failed to convert sources
{:tag :shadow.build.closure/convert-error, :sources [[:shadow.build.npm/resource "node_modules/openpgp/dist/openpgp.js"]]}

beders06:08:07

Here's what I did:

npm install --save openpgp 

beders06:08:35

then in a ns decl: :require ["openpgp" :as openpgp]

beders06:08:05

error was caused by

Caused by:
RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.

INTERNAL COMPILER ERROR.
Please report this problem.

null
  Node(FUNCTION ): node_modules/openpgp/dist/openpgp.js:38406:70
SymmetricallyEncrypted.prototype.encrypt = async function (algo, key) {
  Parent(CALL): node_modules/openpgp/dist/openpgp.js:38406:70
SymmetricallyEncrypted.prototype.encrypt = async function (algo, key) {

beders06:08:10

so it looks like the code requires async/await (which is EcmaScript 2017).

beders06:08:24

Is that the issue here? Do I need to translate it with babel first?

beders06:08:52

thanks for the help and if there's a tip jar somewhere for shadow-cjls, let me know šŸ™‚

thheller07:08:02

@beders looks like a bug in the closure compiler. that INTERNAL COMPILER ERROR. message is from Closure not shadow-cljs.

thheller07:08:10

it reports many more errors when compiling that file

thheller07:08:23

openpgp.js:34964: ERROR - This code cannot be converted from ES6. Undecomposable expression: Please rewrite the yield or await as a separate statement.

thheller07:08:46

not much we can do for now. you could probably process it with babel first but that is not usually recommended or required.

thheller07:08:41

maybe I should switch all pre-processing of node_modules to babel. currently its only down when the file has import/export

thheller08:08:23

@beders I forgot that you can set :js-options {:language-out :ecmascript-2017} which will skip the transpilation

šŸ‘ 4
thheller08:08:36

but only works in modern browsers with async support

chrisetheridge08:08:38

i feel like this is a dep error?

thheller08:08:57

yes, probably guava

thheller08:08:16

check which guava version is on the classpath. shadow-cljs --cli-info should do it

chrisetheridge08:08:57

thank you. did deps-tree go in the new ver?

chrisetheridge08:08:17

[maven] com/google/guava/guava/20.0/guava-20.0.jar

thheller08:08:03

deps-tree was tools.deps so its currently not available

thheller08:08:28

20.0 is the old version. I don't get how that is used though

thheller08:08:00

it should be [com.google.guava/guava "25.1-jre"]

chrisetheridge08:08:05

yeah donā€™t worry, using 25.1-jre worked

chrisetheridge08:08:09

haha yeah that one worked perfectly

thheller08:08:33

can you share your :dependencies? I wonder how the old guava ends up on there

chrisetheridge08:08:38

could be expound or orchestra. deps i havenā€™t looked at in depth before

thheller08:08:56

nah shadow-cljs also brings in expound so its not that

chrisetheridge08:08:00

is it possible to get more context with this error?

[2018-08-20 10:43:41.614 - INFO] :shadow.build.npm/js-invalid-requires - {:requires [{:line 37, :column 17}]}

thheller08:08:38

hmm weird that should be including the filename the require was in

chrisetheridge08:08:49

yeah unfortunately thatā€™s all i get šŸ˜•

chrisetheridge08:08:25

is that a require within a cljs file?

chrisetheridge08:08:36

or is this after cljs has been compiled?

thheller08:08:39

nah its usually not important

chrisetheridge08:08:47

iā€™ll ignore then

thheller08:08:55

some JS files have require("./foo/" + bar) type stuff

chrisetheridge08:08:15

nice. it took me 20 minutes to move from project.clj to shadow on this project! šŸ˜„

chrisetheridge08:08:20

literally no hiccups

thheller08:08:52

well except for the deps stuff šŸ˜‰

chrisetheridge08:08:01

haha well that was luckily pretty small šŸ˜‰

chrisetheridge08:08:10

and iā€™m used to those errors now, from my fight with jackson

thheller08:08:16

btw [cognician/base "336" :exclusions [com.google.guava/guava]]

thheller08:08:40

maybe need to do the deps exclusion for the other cognician things?

chrisetheridge08:08:56

yeah iā€™ll do that too, thank you

thheller08:08:12

I'm guessing that the guava deps comes from there

chrisetheridge09:08:40

so this is new:

chrisetheridge09:08:54

getting a lot of those in my console

thheller09:08:33

Cannot read property 'cwd' of undefined

thheller09:08:02

its the raven include causing the rest of the errors

thheller09:08:28

it fails to load so all that depend on it also fail to load

thheller09:08:45

error is probably more graceful without :loader-mode :eval

chrisetheridge09:08:52

ah, yes, there are two types of ravens. one for client and one for server (node)

chrisetheridge09:08:54

i was using the node one šŸ™‚

chrisetheridge09:08:52

can shadow-cljs deploy to maven?

thheller09:08:07

not at the moment

chrisetheridge11:08:46

if it uses deps.edn to resolve, then i assume yes?

chrisetheridge12:08:14

ah i see. iā€™d need to add a ā€œwagonā€, via Pomegranate

chrisetheridge12:08:13

so i can work around this (by using a build clj script), but it would be great if we could specify wagons in build config

thheller12:08:01

@biscuitpants using tools.deps did have too many bugs so currently it doesn't use tools.deps and no s3 is not supported

chrisetheridge13:08:59

ah okay @thheller yeah i see its using a mix of custom code and also pom

thheller13:08:58

I don't have access to any s3 repo so I can't easily test anything regarding that

thheller14:08:18

for now I'd recommend lein/deps.edn for that since I have never looked into anything related

chrisetheridge15:08:31

have you ever worked with pnpm ?

thheller15:08:41

I did a few tests yes but never in a real project

thheller15:08:53

it seems good but all the symlinks may confuse shadow-cljs

thheller15:08:53

dependencies are also installed weirdly

chrisetheridge15:08:14

i think it does unfortunately, worthwhile to open an issue? iā€™m not sure if you aim to support it

thheller15:08:14

at that point I may as well write my own npm package installer šŸ˜‰

thheller15:08:39

pnpm pretty heavily abuses the nested installs of npm which I absolutely hate

thheller15:08:36

also don't know how it deals with version conflicts yet

chrisetheridge15:08:37

interesting. i didnā€™t know that. i found their method of installing (and sharing deps) to be clever

chrisetheridge15:08:55

but, i have not used it too much yet

thheller15:08:43

its pretty darn fast so thats real nice

heyarne17:08:53

Can I trace module dependencies with shadow-cljs? I know about shadow-cljs.build.release-report, but can I get more fine-grained info? for example "which namespaces require cljs.pprint")

thheller17:08:09

@arne-clojurians there is a (shadow.cljs.devtools.api/find-resources-using-ns 'cljs.pprint) but its very basic

thheller17:08:37

use it from shadow-cljs clj-repl or nrepl

heyarne17:08:48

alright, i'll give it a try

heyarne17:08:31

can't repeat it often enough: super nice tool and your support is always helpful. thanks!

heyarne17:08:59

:resolve is just meant for js packages, right? or can i easily switch debux for debux-stubs like described here? https://github.com/philoskim/debux#3-installation

thheller17:08:44

its only for JS yes. I'm a bit hesitant addding something similar for CLJS since it would be incompatible with any other tool

thheller17:08:57

I think the whole solution of stubs is kinda bad though. you can do the stubs using deps.edn or project.clj if you really have to

thheller18:08:38

the functionality already exists though

thheller18:08:01

BUT the issue is that the stubs have the same namespace so it wouldn't work

heyarne18:08:01

It's not such a big issue for me tbh. I can also just clean up after myself and remove the requires before doing a release

heyarne19:08:47

what's kind of interesting is i thought google closure compiler would be smart enough to do it by itself. i had a :require redux.core :refer [dbg] in a namespace that lands in production, but no call to dbg in it. still a lot of the pprint and analyzer stuff landed in the optimized file, resulting in something like a 150kbit pre-gzip (~50kb gzipped) decrease when i removed it

thheller19:08:21

closure is heavily dependent on how the code is written and many things CLJS libs do just can't be eliminated