This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-24
Channels
- # announcements (2)
- # beginners (131)
- # calva (4)
- # cider (29)
- # cljs-dev (18)
- # cljsrn (8)
- # clojure (61)
- # clojure-czech (1)
- # clojure-europe (5)
- # clojure-italy (14)
- # clojure-nl (6)
- # clojure-switzerland (2)
- # clojure-uk (125)
- # clojuredesign-podcast (10)
- # clojurescript (25)
- # clojutre (15)
- # clr (4)
- # code-reviews (4)
- # data-science (1)
- # emacs (1)
- # events (2)
- # fulcro (12)
- # graalvm (4)
- # jobs (2)
- # keechma (1)
- # off-topic (1)
- # pathom (18)
- # re-frame (3)
- # reagent (7)
- # shadow-cljs (106)
- # spacemacs (33)
- # sql (12)
- # xtdb (5)
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?
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
I'm not sure this works with CLJS code though as that still uses the "old" goog.require and discards the return value
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.
didn't spend much time on goog.module. seems like ES6 would be a better choice overall
So the question is why google uses goog.module in the first place instead of just using es6?
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?
Yeah, we had an exception thrown during a hook invocation but shadow cli exited with a 0 so our CI job didn't fail
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!
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?
agreed. try [email protected]
it should properly fail if a hook fails
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;
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;
@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!
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)
There鈥檚 a deftest
statement in the test file, with two assertions.
I fat-fingered shadow-cljs restart
. My bad. Thanks for the help though!
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.@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
Gotcha
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.
thanks, ill grab u an example in a bit
Using shadow.cljs.devtools.api
, is there a way to get the number of build warnings? I would like to assert they鈥檙e zero
would warnings-as-errors help? Antonio asked for that a while ago but I forgot about it
I see config in shadow-cljs and clojurescript compiler to ignore warnings, but not to treat them as errors
@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
that鈥檚 awesome, thanks
@thheller that reminds me, we were seeing an issue yesterday that I wanted to talk to you about
an NPM package ended up in our 2nd bundle and it errored out because $jscomp
wasn鈥檛 in scope
the reason being we have :output-wrapper true
in the main bundle so $jscomp
is never in the global scope
is this expected? I thought :output-wrapper true
could work with modules?
it likely just wanted to use $jscomp
but :advanced
compilation got rid of it or renamed it
polyfills are currently a bit ugly since it still does the separate compilation steps
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
hmm there might be problems with polyfills and caching? polyfills aren't handled very cleanly currently
@thheller did you ever work with graaljs?
@thheller sorry dropped the ball on this
uh it was an NPM package that needed a polyfill
that鈥檚 what it was
this is the package
@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?
just warnings in our own code
that鈥檇 be helpful - I think we have deps that warn right now that we can鈥檛 upgrade
will do