Fork me on GitHub
#shadow-cljs
<
2019-01-30
>
aisamu17:01:21

Hi! Are build reports supported on :npm-module targets? This the output I get with after clearing the cache and node_modules:

...
[:npm] Build completed. (163 files, 104 compiled, 0 warnings, 35.70s)
shadow-cljs - config: /home/jenkins/jakarta/shadow-cljs.edn  cli version: 2.7.22  node: v9.11.2
failed to run function: shadow.cljs.build-report/-main
{:tag :shadow.cljs.devtools.cli/clj-run, :main-sym shadow.cljs.build-report/-main}
ExceptionInfo: failed to run function: shadow.cljs.build-report/-main
        clojure.core/ex-info (core.clj:4739)
...
Caused by:
NoSuchFileException: .shadow-cljs/release-snapshots/npm/latest/goog.debug.error.js.map
        sun.nio.fs.UnixException.translateToIOException (UnixException.java:86)
        sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:102)
        sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:107)
        sun.nio.fs.UnixFileSystemProvider.newByteChannel (UnixFileSystemProvider.java:214)
        java.nio.file.Files.newByteChannel (Files.java:361)
        java.nio.file.Files.newByteChannel (Files.java:407)
        java.nio.file.Files.readAllBytes (Files.java:3152)
        shadow.build.closure.SourceMapReport.getByteMap (SourceMapReport.java:57)
        shadow.cljs.build-report/extract-report-data/fn--991/fn--993 (build_report.clj:126)
....

aisamu17:01:55

(`.shadow-cljs/release-snapshots/npm/latest/goog.debug.error.js.map` is indeed missing, but out of the 33 goog.* ns's in that folder, only 7 have sourcemaps)

thheller17:01:56

oh. yeah thats a bug.

thheller17:01:23

those files were completely removed by DCE and are only there for compatibility reasons

thheller17:01:44

ie. .shadow-cljs/release-snapshots/npm/latest/goog.debug.error.js is empty

thheller17:01:37

but build report for npm-module isn't very useful since you are going to consume it somewhere else anyways

thheller17:01:48

eg. you let webpack fill in your npm requires

aisamu17:01:54

OK! I was mostly interested on checking whether the fdef's I wrote were leaking into prod, since everything is always on the classpath. (not enabled, since I'm not using orchestra, but present and unnecessarily increasing the payload)

thheller17:01:34

fdefs will never be removed if they are in a namespace that was included in the build

thheller17:01:12

(unless you manually hide them behind some (when ^boolean js/goog.DEBUG (s/fdef ...)))

thheller17:01:51

spec in general doesn't work with DCE unfortunately

aisamu17:01:35

Yup, those were my fears... but it's nice to have a confirmation! Thanks for being so helpful!

aisamu20:01:01

Hello again! Is it expected to get a compilation error when using #shadow/env with an unset var on release builds?

$> npx shadow-cljs release npm
...
-> Closure - Optimizing ...
Closure compilation failed with 1 errors
--- goog/base.js:3
Invalid CLOSURE_DEFINES definition
The compile task works without issue, and setting the var to nothing or the empty string also works (e.g. $> THE_VAR= npx shadow-cljs release npm) The config contains
:closure-defines {the.ns/THE_VAR #shadow/env "THE_VAR"}
and the.nscontains a (goog-define THE_VAR)

thheller20:01:55

@aisamu if you only care about the THE_VAR in development use the :dev map

thheller20:01:11

:dev {:closure-defines {the.ns/THE_VAR ....}}

thheller20:01:05

and just set :release {:closure-defines {the.ns/THE_VAR ""}}

thheller20:01:10

it may not like nils

aisamu20:01:47

I might need it for both, but I can go around it by checking that it exists before calling shadow. Thanks! (yup I believe goog-defines can't be nil)

thheller20:01:14

I can fix it so it doesn't return nil when not found

❤️ 5
aisamu20:01:40

That'd be very nice, thanks!

thheller20:01:50

I never recommend using env vars so the feature isn't used much 😛

aisamu20:01:54

Yup, I read that! And I see that it's also not on the manual, so I'm well aware I'm playing with fire here... It's mostly to be compliant with the existing webpack project that uses the cljs modules

thheller20:01:53

@aisamu should be fixed in 2.7.23

🙏 5
aisamu20:01:10

Again, thanks a lot!