i’m trying to use PDFJS, which uses a web worker. the web worker is already distributed in the pdfjs-dist npm module under build/pdf.worker.js. what’s the right way to tell shadow-cljs about that file and that it need to be served during development and copied & minified during production?

I see the 6.4 Web Workers in the manual, but that is for cljs code, i think

@lee.justin.m when I npm install pdfjs there is no such file?

Hi. I seem to remember that there was a way to see how much size each library is adding to the total size of the release build using shadow-cljs. Is that a thing, or am I mis-remembering?

@mjmeintjes very crude version exists yes. see https://clojureverse.org/t/help-wanted-release-bundle-size-visualization/871/9?u=thheller

Great, thanks. Exactly the post I was searching for.

Haven't tested this in a while. might totally not work anymore 😛

No worries, just glad I'm not going mad as I was sure I had seen it somewhere but couldn't find it anywhere.

yeah not added to the docs yet

kinda want to have an actual visualization first 🙂

@lee.justin.m ah I looked at the wrong package. from what I can tell you don't need to use their bundle but instead you create a (ns your.app.worker (:require ["pdfjs-dist/lib/core/worker"])) and then let shadow-cljs build it for you

but you can just (:require ["pdfjs-dist/build/pdf.worker"]) as well

@thheller so I thought with web workers you typically have to specify a uri in the worker constructor, which then goes and fetches the source at that uri and then runs it. in javascript all I do is

const PDFJS = window.PDFJS;
PDFJS.workerSrc = '/pdf.worker.js';

for what it is worth: i think it would be really cool to have shadow-cljs build it for me since the optimizations might be better. i was just trying to do it the easy way first

so the "trick" with web workers in shadow-cljs is that is uses the code splitting

meaning that code used only by the worker will also only be loaded when the worker is started

the file that :web-worker true generates is a standalone worker file, ie. you call it with the webworker constructor

I expanded the webworker section with an example

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

Hmm, new error from the closure compiler in 2.1.7:

Closure compilation failed with 1 errors
--- node_modules/dialog-polyfill/dialog-polyfill.js:692
this language feature is only supported for ECMASCRIPT6 mode or better: block-scoped function declaration. Use --language_in=ECMASCRIPT6 or ECMASCRIPT6_STRICT or higher to enable ES6 features.

the "problem" with the pre-built pdfjs.worker.js is that it basically doubles the code your user has to download

first the normal pdfjs and then the worker file

code splitting would be better but I don't know exactly what pdfkit expects from the worker

@theasp that worked before?

Yeah, on Friday 🙂

and before...

https://github.com/GoogleChrome/dialog-polyfill

which version?

ah nvm got it

weird thing is I set ECMASCRIPT_NEXT language mode

which is way past ES6 so no idea why it wants es6

I was using 2.1.4 on Friday

Yeah, I was reading that

Either way, I blame Google

yeah I upgrade to the newest closure compiler verison in 2.1.7

it had some improvements I wanted but I guess also some new bugs

Said anyone who upgraded anything ever

I'll see if I can figure something out

i read through the modules section again. if i understand correctly: i should create an empty cljs file for the worker that includes the entry point for the worker code. then declare that file as a web worker module and shadow will be able to serve it and pdfjs will be able to use it

I don't know about pdfjs but yes thats the idea

gotta love those helpfull errors from closure

--- null:-1
Missing externs definition for Symbol. Did you forget to include the ES6 externs?

ECMASCRIPT_NEXT for output, or input?

forgot that I acutally set it to ES5 for node_modules files

input

Ahh

but if I set it higher I get the error above

babel in theory is used for everything es6+ in node_modules for reasons such as this

but the file is not detected as es6 and AFAICT it isn't either

don't really understand what its complaining about

https://github.com/google/closure-compiler/commit/41331b3d98612101fe09bd01bdd5b305526281e5

I don't understand why we still need a dialog polyfill in 2018

to be honest I had no idea that a dialog api even existed

well .. I'm just going to bump the language in

I don't think it does anything you couldn't do manually

yeah I've always done dialogs manually. takes 5 lines of code or so. no idea why you'd need a standard api for that

It's supposed to handle focus and modalness in an accessible way

yeah I guess its a common enough thing to make it standard

@theasp pushed 2.1.8 which seems to fix it

\o/

do you use joker as a linter? it is cranky because of the extension to the ns and I don’t think it is extensible in thatway

everything except :default is standard clojurescript so it should support that

but no I don't use it

i think it doesn’t like the strings

no big deal

@thheller My mystery console.clear() call is no longer happening.

I actually added a (js/console.clear) to my :before-load hook. I kinda like it.

haha

but not really sure if I should add it as an option. seems fine when done in :before-load

Yeah, probably shouldn't

@thheller just wanted to let you know that after upgrading from 2.1.6 -> 2.1.8 (2.1.7 didn’t compile) I am running into some issues where NPM deps are no longer coming in correctly (some libraries that I’m requiring are now resolving to undefined)