Fork me on GitHub
#shadow-cljs
<
2019-01-26
>
currentoor07:01:13

Has anyone used jsPDF with shadow? doing this causes 14 identical errors in the JS console

currentoor07:01:14

(ns foo.bar 
  (:require ["jspdf" :as jspdf]))

(jspdf.)

currentoor07:01:30

jspdf.min.js:formatted:1787 jsPDF PubSub Error t.existsFileInVFS is not a function TypeError: t.existsFileInVFS is not a function

currentoor07:01:11

but if i load jsPDF from a CDN, then it works fine via (js/jsPDF.)

currentoor07:01:10

and the weird thing is, if i have the lib loaded from a CDN, then the shadow require version works without error also

currentoor07:01:46

could that mean shadow/npm is not pickup a transitive dependency, but it is loaded when i use the CDN?

David Pham09:01:26

@lilactown exactly. I can use the repl normally, but can’t pprint

thheller10:01:09

@currentoor jsPDF looks like a terrible package. is leaks a bunch of stuff into the global scope

thheller11:01:55

not sure what webpack is doing differently

thheller11:01:23

I suspect that jsPDF relies on those leaked globals in some way but closure decides to rename them at some point

thheller11:01:44

which would explain why the CDN + require'd version work together since the CDN version creates those globals

currentoor19:01:34

hmm looks like it’s the leading PDF builder in JS, is there anything that can be done? (i guess using the CDN is the backup)

thheller19:01:26

I can't figure out what closure is doing that messes things up

thheller19:01:42

if I just take the source directly it loads normally

thheller19:01:08

so it must be something that closure does but I can't figure it out

thheller19:01:51

since this is a case of .min.js it would fix the issue 😉

thheller19:01:41

but the package doesn't follow any established JS packaging standards and just does something random it seems

currentoor19:01:52

oh wow thanks for doing all this

currentoor19:01:02

you always go above and beyond, thank you so much!

thheller19:01:47

can't let a random npm package defeat me 😉

currentoor19:01:02

the other option is pdfkit, but that was having browserify issues

currentoor19:01:11

it looks like it requires browserify to work

currentoor19:01:44

i do have the option of requiring either library in a script tag, so i might just do that

currentoor19:01:53

i didn’t know packages could be tied to browserify like that

currentoor19:01:03

seems like a weird thing to be tied down to

thheller19:01:34

nah the docs are probably just old

thheller19:01:46

let me see whats weird about that package 😉

thheller19:01:02

hmm no indeed it requires a browserify plugin

thheller19:01:44

gotta love the shit people come up with to build their libs 🙂

currentoor19:01:26

yeah it’s crazy 😅

thheller20:01:08

FWIW you can fix the issue by doing (set! js/window.existsFileInVFS (fn [] false))

thheller20:01:38

don't know why it is trying to use that from the global or why its different in webpack

thheller20:01:57

but that fixes it (if you do it before calling the jsPDF constructor)

thheller20:01:10

ha I found it ...

thheller20:01:30

closure compilation strips the "use strict"; for some reason

thheller20:01:25

> I'm closing this - it's not well understood, but it is by design.

currentoor01:01:34

that is strange

metacritical13:01:57

@thheller I am writing a electron + shadow.cljs app and i have a particular use case where once the app is loaded i am trying to read some config written in cljs file that is not in the namespace. i.e

(defn load-global-config
  ([] (load-file “~/.b42/init.cljs”))
  ([config-file] (load-file config-file)))
I am getting an error goog.nodeGlobalRequire is not a function. Also it seems the foreign-lib is also not supported. Could there be a possible way to to this in an electron app?

thheller14:01:19

@metacritical I have no idea what you are asking. that code snippet does not tell me anything. you can't load .cljs at runtime unless you are using self-hosted CLJS

thheller14:01:29

by load-file I assume you mean cljs.core/load-file which is only for self-hosted CLJS and not usable otherwise

thheller14:01:21

don't see how foreign-libs are involved in that though

thheller14:01:23

its a different story if the file you want to load is just EDN data you want to access

thheller14:01:36

but actual CLJS code you want to evaluate will only work in a self-hosted environment

metacritical14:01:41

@thheller I understand what you are saying so my next question is can i have a self hosted clojurescript with a target

:node-script

thheller14:01:16

yes, but it will require some work on your part.

thheller14:01:47

I added support for browser based self-hosted stuff a while ago

metacritical14:01:09

Yes and i used it, and it is great!

thheller14:01:27

so you'd basically need to take this namespace

thheller14:01:41

take out all the browser related parts and write a node.js implementation

thheller14:01:35

in essence you want to read the "index" from the filesystem

metacritical14:01:40

Aha, the current shadow docs has :bootstrap as a target to support the self hosting in browser, how would node target be?

thheller14:01:41

and subsequent files as well

thheller14:01:47

instead of requesting things via XHR and stuff

thheller14:01:07

the bootstrap stuff is identical, the generated index is identical. no changes there.

thheller14:01:36

only the "bootstrap" namespace that loads everything is different

metacritical14:01:03

I understand, so i should submit a patch for this?

thheller14:01:40

not needed. you can do this in your app, nothing in shadow-cljs itself needs to change to support this

thheller14:01:52

if you build it general enough I'll consider accepting a PR to include it

thheller14:01:20

but bootstrapping can be optimized for your particular needs

thheller14:01:37

so making something general might not be optimal depending on what you are actually trying to do

metacritical14:01:48

Aah, sure thats actually helpful thankyou!

thheller14:01:30

also things are a bit more complicated for electron if you want to support loading files from .asar and stuff

metacritical14:01:47

Currently i am not considering .asar support! but what you suggested is quite helpful.