Fork me on GitHub
#shadow-cljs
<
2019-09-24
>
g7s08:09:46

So, I want to require a google closure compatible library and I see in the docs that there is no :libs option, so I just go ahead and :require as normal?

thheller08:09:19

yes, just put it on the classpath as normal

thheller09:09:13

the closure library started using goog.module as well if you need a reference https://github.com/google/closure-library/blob/master/closure/goog/i18n/dateintervalsymbols.js

thheller09:09:56

I'm not sure this works with CLJS code though as that still uses the "old" goog.require and discards the return value

thheller09:09:12

so it might only work with the declareLegacyNamespace thing

g7s09:09:46

yeah I just checked and shadow doesn鈥檛 work with the new goog.module. I guess I have to switch to the old format until CLJS supports the new format.

thheller09:09:06

can you give me an example of what you tried?

thheller09:09:25

you could just use ES6 which works sort of fine

thheller09:09:02

didn't spend much time on goog.module. seems like ES6 would be a better choice overall

g7s09:09:01

If I use ES6 will I get all the benefits of advanced closure compilation?

thheller09:09:05

but there are rough edges when trying to import JS from npm in ES6 code

thheller09:09:23

so you might be better of using the old format

thheller09:09:38

well .. can't import from npm at all there

thheller09:09:43

so depends on what you really need 馃槢

g7s09:09:54

For the specific use case I do not want to import anything from npm

g7s09:09:59

so I guess it is fine

g7s09:09:38

So the question is why google uses goog.module in the first place instead of just using es6?

donavan09:09:50

Morning 馃檪 I assume there is a way to exit the build when there is an exception during the build but I can't seem to find it. Am I missing it in the docs somewhere?

thheller09:09:50

exit a build?

donavan09:09:56

Yeah, we had an exception thrown during a hook invocation but shadow cli exited with a 0 so our CI job didn't fail

thheller09:09:06

yes, exceptions in hooks are caught and logged

thheller09:09:15

they aren't supposed to throw 馃槈

thheller09:09:01

what are you doing that you want to throw?

donavan09:09:00

Ah ok, well we pushed a bug in a supporting library that trickled down to some missing config in the shadow build and didn't catch it in CI. We thought we were just missing some piece of config or the correct cli args to get the build to fail fast. We can add in some detection on our side. Thanks!

thheller09:09:46

I could totally remove this restriction and let hooks throw

thheller09:09:06

can't remember why I added that in the first place

donavan09:09:33

I personally think it would be better if exceptions thrown in during any build stage caused the build to exit with a non-zero status; perhaps when passed a cli flag so as to not effect current behaviour?

thheller09:09:32

agreed. try [email protected] it should properly fail if a hook fails

donavan09:09:27

Awesome, will do

donavan10:09:11

Thanks, that works perfectly

g7s09:09:56

I mean if advanced compilation works

thheller09:09:10

historic reasons. ES6 didn't exist when goog.module was introduced

thheller09:09:18

closure compiler didn't support ES6 for a long time

g7s09:09:38

I see.. still their styleguide mentions nothing about ES6 only goog.module

g7s09:09:51

Ok thanks for the info 馃檪

g7s09:09:31

To give you a hint of the test I did was to define a goog.module such as this

g7s09:09:43

goog.module('test.Foo');

class Foo {
    /**
     * @param {string=} a
     */
    constructor(a) {
        /**
         * @type {string}
         */
        this.a = a || "G7S";
    }

    /**
     * @return {string}
     */
    say() {
        return "Hello " + this.a;
    }
}


exports = Foo;

g7s09:09:06

and then :require it in a cljs namespace

g7s09:09:33

but returns undefined

g7s09:09:47

switching it to goog.provide works as expected

thheller09:09:25

goog.module('demo.googClass');
goog.module.declareLegacyNamespace();

class Foo {
    /**
     * @param {string=} a
     */
    constructor(a) {
        /**
         * @type {string}
         */
        this.a = a || "G7S";
    }

    /**
     * @return {string}
     */
    say() {
        return "Hello " + this.a;
    }
}

exports.Foo = Foo;

thheller09:09:39

[demo.googClass :refer (Foo)]

thheller09:09:41

this works fine

thheller09:09:31

(changed the name to fit into my shadow-cljs dummy test namespaces)

g7s09:09:33

Yeah I see that it works with the declareLegacyNamespace thing

g7s09:09:08

I will either use this for now or migrate to es6

g7s09:09:15

thanks again for your help!

thheller09:09:42

in case you are interested

thheller09:09:17

es6 should mostly work without tricks

g7s09:09:03

thanks this is helpful

mynomoto13:09:33

@thheller it turned out that using the :npm-module target and running jest on the test files did the trick for testing snapshots for react-native components. shadow already supports it, thanks!

馃憤 4
jimberlage15:09:25

Anyone know what I need to do to get a test picked up by shadow-cljs? I have a file, test/my_project/core_test.cljs, and in shadow-cljs.edn I have :source-paths ["src" "test"], as well as a build defined as {:test {:target :node-test :output-to "unit-tests.js" :autorun true}}. However, when I go to run shadow-cljs release test, I see

[:test] Compiling ...
========= Running Tests =======================

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
===============================================
[:test] Build completed. (27 files, 1 compiled, 0 warnings, 4.51s)

jimberlage15:09:46

There鈥檚 a deftest statement in the test file, with two assertions.

thheller15:09:58

did you restart after changing source-paths?

thheller15:09:39

no other warnings on startup?

jimberlage15:09:51

I fat-fingered shadow-cljs restart. My bad. Thanks for the help though!

jimberlage16:09:28

Although when I do run tests, I get an error like this:

/Users/jberlage/toto/node_modules/react-native-keychain/index.js:2
import { NativeModules, Platform } from 'react-native';
       ^

SyntaxError: Unexpected token {
    at Module._compile (internal/modules/cjs/loader.js:872:18)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:947:10)
    at Module.load (internal/modules/cjs/loader.js:790:32)
    at Function.Module._load (internal/modules/cjs/loader.js:703:12)
    at Module.require (internal/modules/cjs/loader.js:830:19)
    at require (internal/modules/cjs/helpers.js:68:18)
    at /Users/jberlage/toto/unit-tests.js:750:684
    at Object.<anonymous> (/Users/jberlage/toto/unit-tests.js:842:3)
    at Module._compile (internal/modules/cjs/loader.js:936:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:947:10)
Regression, or should I just lose the :node-test target entirely for react-native projects? The tests are limited to stuff that would compile and run on node, but perhaps I can鈥檛 avoid importing something that will break.

thheller16:09:19

@jimberlage ask @mynomoto he got tests running for react-native. no clue whats involved. I only know that they can't run directly in node without compilation

thheller16:09:57

see the comment above about jest

Drew Verlee17:09:27

So a npm package i need to use is including (what seems to be) compiled javascript in the main js file. They then used that compiled js in the package. 1. Any idea's why someone would handle deps that way? 2. Any idea why it would interfere with importing the package? Prior to removing it, i couldn't import the package correctly.

thheller17:09:00

do you have an example? sounds a bit abstract to me?

thheller17:09:56

is it using dynamic import()?

Drew Verlee20:09:24

thanks, ill grab u an example in a bit

arohner17:09:29

Using shadow.cljs.devtools.api, is there a way to get the number of build warnings? I would like to assert they鈥檙e zero

thheller17:09:27

would warnings-as-errors help? Antonio asked for that a while ago but I forgot about it

thheller17:09:47

you can in theory get the warnings but the API isn't pretty

arohner17:09:13

yeah, warnings-as-errors would work

arohner17:09:19

how do I do that?

arohner17:09:47

I see config in shadow-cljs and clojurescript compiler to ignore warnings, but not to treat them as errors

thheller17:09:11

yeah thats not in yet but I have a few minutes so should be easy to add

thheller17:09:35

@arohner @anmonteiro [email protected] adds :compiler-options {:warnings-as-errors true} or :compiler-options {:warnings-as-errors #{:undeclared-var}} to only error out on specific ones

anmonteiro17:09:03

that鈥檚 awesome, thanks

thheller17:09:18

should have opened a ticket. I forgot about it completely 馃槢

anmonteiro17:09:27

@thheller that reminds me, we were seeing an issue yesterday that I wanted to talk to you about

anmonteiro17:09:54

an NPM package ended up in our 2nd bundle and it errored out because $jscomp wasn鈥檛 in scope

anmonteiro17:09:28

the reason being we have :output-wrapper true in the main bundle so $jscomp is never in the global scope

anmonteiro17:09:57

is this expected? I thought :output-wrapper true could work with modules?

thheller17:09:43

hmm an npm package shouldn't end up using $jscomp

thheller17:09:06

it likely just wanted to use $jscomp but :advanced compilation got rid of it or renamed it

thheller17:09:30

polyfills are currently a bit ugly since it still does the separate compilation steps

thheller17:09:24

do you know which npm package wanted to access $jscomp?

lilactown17:09:56

I had a gcc module that had errors referring to $jscomp the other day

lilactown17:09:34

clearing out my build output seemed to fix it - this was in the middle of moving from figwheel to shadow so not sure what the actual cause was

thheller17:09:01

hmm there might be problems with polyfills and caching? polyfills aren't handled very cleanly currently

David Pham18:09:10

@thheller did you ever work with graaljs?

thheller19:09:39

I did a few experiments yes but no actual use

anmonteiro19:09:57

@thheller sorry dropped the ball on this

anmonteiro19:09:08

uh it was an NPM package that needed a polyfill

anmonteiro19:09:10

that鈥檚 what it was

anmonteiro19:09:31

this is the package

anmonteiro21:09:21

@thheller another question I have regarding treating warnings as errors (I haven鈥檛 gotten around to trying it yet): I assume a warning in a third party dep won鈥檛 fail my build?

馃檹 8
anmonteiro21:09:25

just warnings in our own code

thheller21:09:35

no any warning will fail

thheller21:09:39

I could add a flag though

anmonteiro22:09:55

that鈥檇 be helpful - I think we have deps that warn right now that we can鈥檛 upgrade

thheller22:09:28

open an issue so I don't forget please

thheller22:09:32

about to head to bed