This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-07
Channels
- # announcements (2)
- # beginners (25)
- # calva (16)
- # cljdoc (37)
- # cljsrn (24)
- # clojure (204)
- # clojure-nl (4)
- # clojure-spec (34)
- # clojure-uk (3)
- # clojurescript (13)
- # cursive (8)
- # data-science (3)
- # dirac (21)
- # figwheel-main (1)
- # luminus (3)
- # off-topic (45)
- # pedestal (3)
- # planck (2)
- # re-frame (5)
- # shadow-cljs (270)
- # spacemacs (5)
@caleb.macdonaldblack see https://github.com/thheller/shadow-cljs/issues/468#issuecomment-480494400 for some polyfill related stuff
Thanks!
@caleb.macdonaldblack what kind of compatibility issues?
With an older browser. Im not as experienced in dealing with these issues so I was looking for some direction. It looks like a need some polyfills for a number of missing features such as fetch
and object.assign
in order to work with older versions of safari. Im using http://polyfill.io.
Thank you for your help. Although at this point I'm not sure if I need any more help at the moment. Those two issues with fetch
and object.assign
I was able to resolve with a polyfill. After that I was able to load the app at least. I have more issues with css after which I stopped working on this. I'm going to talk to the project owner tomorrow and discuss whether or not it's worth investing more time in this issue.
I'm also not sure if the issue is with cljs or an npm lib as I don't have source maps setup and I was investigating the issue with advanced compilation with http://browserstack.com. However I'm pretty sure it's an npm library though, I'm not doing fetch
or object.assign
with js interop or anything.
using something like http://polyfill.io is fine. you could also make shadow-cljs do it but if you have something that works you can just use that
Is that done using :prepend
as mentioned in the issue that orestis linked?
I did try that, however I had another issue where I used let
instead of var
directly in the index.html
file that I didn't know about at the time so I guess I assumed it wasn't working. I'll remove the polyfill now and give that a try.
polyfill detection in npm code is not as reliable as I'd like it to be so it might not work
Nah that didn't work for me sorry.
forgive me sending the screenshot. I'm using a browserStack vm
ok yeah thats a bug then. it is supposed to detect the polyfills properly and Object.assign is definitely one of them
I posted my shadow-cljs.edn just to rule out any mistakes I may have made setting those compiler options
If I was to guess I'd say https://github.com/aws-amplify/amplify-js that I use for auth is the library causing my errors. I can see a few instances where they use Object.assign
Let me know if there is anything I can do to help you debug this issue or further clarify it's not a mistake on my end
Oh I also had one other polyfill issue with performance.now
that I forgot to mention. I didn't find that here though: https://cljs.github.io/api/compiler-options/rewrite-polyfills, so I'm not sure if shadow could help me there
do the errors happen directly on load or do you need to call something specific first?
On load I believe. I still get the error after omitting the .init()
call.
in 2.8.28
I added a new :js-options {:babel-preset-config {:targets {:safari 7}}}
which lets you configure babel to inject certain polyfills into JS code
so basically this config https://babeljs.io/docs/en/babel-preset-env#options
Amazing! Thank you so much
Sorry I just got around to testing this and I'm still not able to get this to work for me. I've added :js-options {:babel-preset-config {:targets {:safari 7 :ie 11}}}
and :compiler-options {:rewrite-polyfills true :output-feature-set :es3}
to my shadow-cljs and neither safari 7 nor ie 11 seem to have any polyfills. ie Is missing Promise and safari is missing Object.assign
.
And I've updated shadow-cljs to the new version aswell
I did try without that also and had the same effect
There isn't one
there is no babel-worker
directory
right .. my bad ...babel is only used for ES6+ code in node_modules, so if you only import ES5 code the polyfills won't trigger
Is there any reason that newer versions o Shadow-CLJS are not printing the socker REPL port on start, only the nREPL?
if you need to know the port you can either configure a fixed port or look at the .shadow-cljs/socket-repl.port
file
Ah, ok. Also, one more thing: I'm adding tests to a project and I saw the :node-tests
target. But somehow, when I import clojure.test
or cljs.test
, it seems that cljs.test/assert-expr
is missing. Is this a known issue?
No, they are not, sorry 🙂
No, this is a test namespace only for ClojureScript
(ns paprika.collection-test
(:require [clojure.test :refer [deftest testing is assert-expr] :include-macros true]
[paprika.collection :as coll]))
And the error:
1 | (ns paprika.collection-test
-------^------------------------------------------------------------------------
Invalid :refer, var cljs.test/assert-expr does not exist
--------------------------------------------------------------------------------
2 | (:require [clojure.test :refer [deftest testing is assert-expr] :include-macros true]
3 | [paprika.collection :as coll]))
4 |
cli version: 2.8.26 node: v10.6.0
This library here uses assert-expr
to extend clojure.test: https://github.com/nubank/matcher-combinators
And I was getting this error while trying to use it on shadow-cljs, and then I tried to fix this bug
I'll try to test on other targets and if it works, should I open an issue?
@mauricio.szabo that function is only used by macros so it must be implemented in CLJ
Thanks for the help!
Okay, with your help I was able to fix the original library.
It does gets me that the library is originally using lein-cljsbuild
, and it does compile there. Is shadow-cljs stricter than lein-cljsbuild?
IIRC nubank had a couple other projects that were written in CLJC but never really used from CLJS
but yeah the default cljs compiler is sometimes a little less strict and lets some things pass without verifying
hello, I just did a bump for an old project, and then shadow its failing with this:
failed to convert sources
{:tag :shadow.build.closure/convert-error, :sources [[:shadow.build.classpath/resource "com/wsscode/pathom/viz/d3-attribute-graph.js"] [:shadow.build.classpath/resource "com/wsscode/pathom/viz/detect-element-size.js"] [:shadow.build.classpath/resource "com/wsscode/pathom/viz/d3-trace.js"]]}
ExceptionInfo: failed to convert sources
shadow.build.closure/convert-sources*/fn--12072 (closure.clj:1434)
shadow.build.closure/convert-sources* (closure.clj:1404)
shadow.build.closure/convert-sources* (closure.clj:1292)
shadow.build.closure/convert-sources (closure.clj:1621)
shadow.build.closure/convert-sources (closure.clj:1549)
shadow.build.compiler/maybe-closure-convert (compiler.clj:1016)
shadow.build.compiler/maybe-closure-convert (compiler.clj:1009)
shadow.build.compiler/compile-all (compiler.clj:1264)
shadow.build.compiler/compile-all (compiler.clj:1128)
shadow.build.api/compile-sources (api.clj:252)
shadow.build.api/compile-sources (api.clj:244)
shadow.build/compile (build.clj:373)
shadow.build/compile (build.clj:364)
shadow.cljs.devtools.server.worker.impl/build-compile (impl.clj:293)
shadow.cljs.devtools.server.worker.impl/build-compile (impl.clj:279)
shadow.cljs.devtools.server.worker.impl/eval14932/fn--14934 (impl.clj:640)
clojure.lang.MultiFn.invoke (MultiFn.java:234)
shadow.cljs.devtools.server.util/server-thread/fn--14646/fn--14647/fn--14655 (util.clj:293)
shadow.cljs.devtools.server.util/server-thread/fn--14646/fn--14647 (util.clj:292)
shadow.cljs.devtools.server.util/server-thread/fn--14646 (util.clj:265)
java.lang.Thread.run (Thread.java:748)
Caused by:
RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.
INTERNAL COMPILER ERROR.
Please report this problem.
Unexpected module type: SCRIPT
Node(NAME d3): com/wsscode/pathom/viz/d3-attribute-graph.js:8:14
const svg = d3.select(element)
Parent(GETPROP): com/wsscode/pathom/viz/d3-attribute-graph.js:8:14
const svg = d3.select(element)
Node(SCRIPT): com/wsscode/pathom/viz/d3-attribute-graph.js:1:0
import * as d3 from "/node_modules/d3/dist/d3.node.js";
Parent(ROOT): [source unknown]
you know how to go around that?@wilkerlucio what is this orginially? import * as d3 from "/node_modules/d3/dist/d3.node.js";
just import ... from "d3";
?
its: import * as d3 from "d3";
the easy fix is probably not using ESM import/export but rather write it in commonjs
you mean switch to require
and module.exports
?
thanks, I'll try replacing and see how it goes
@wilkerlucio try [email protected]
. the entire situation currently is a bit messy since the JS world can't decide how to do ESM->CommonJS interop properly
@thheller awesome, just confirmed it fixed the build 👍
@thheller I just got a different problem, this is code is the fulcro inspect, and now chrome is complaining about encoding:
/Development/third-part/fulcro-inspect/shells/chrome
Error
Could not load file 'out/cljs-runtime/goog.i18n.bidi.js' for content script. It isn't UTF-8 encoded
is that a setting I can change to force utf-8 for everything?
nevermind, seems some transient issue, disabling and reenabling the extension got it back :man-shrugging:
@thheller actually, the problem persists, the extension is not getting loaded, complaining about encoding, i'm working on something else but later I'll get back more to it
you can set :compiler-options {:closure-output-charset "ASCII"}
but that defaults to utf-8 so no idea why it would complain
in normal browser things that is fixed by adding the <meta charset="utf-8">
or content-type
header
no lucky here, it keeps complaining about that bidi i18n file -.-
I was already using :compiler-options {:closure-output-charset "US-ASCII"}
before
I tried now removing, using just ASCII
, but none worked
I can confirm it gets back working when I reverted shadow to version 2.7.6
I can try finding the version that introduced the problem, you think that might be due to some change in closure or maybe cljs?
$ file out/demo-browser/public/js/cljs-runtime/goog.i18n.bidi.js
out/demo-browser/public/js/cljs-runtime/goog.i18n.bidi.js: UTF-8 Unicode text, with very long lines
I opened here, the file looked fine and in utf-8 :thinking_face:
but now for some reason with the reversed version I'm getting a lot of weird bad things happening...
I have that here too
have you seen something like this? after reverting the version I'm getting all sorts of errors that I never saw before:
string.js:58 Uncaught TypeError: Cannot read property 'startsWith' of undefined
at string.js:58
(anonymous) @ string.js:58
util.js:92 Uncaught TypeError: Cannot read property 'contains' of undefined
at Object.goog.labs.userAgent.util.matchUserAgent (util.js:92)
at Object.goog.labs.userAgent.browser.matchOpera_ (browser.js:44)
at useragent.js:126
goog.labs.userAgent.util.matchUserAgent @ util.js:92
goog.labs.userAgent.browser.matchOpera_ @ browser.js:44
(anonymous) @ useragent.js:126
util.cljs:187 Installing CLJS DevTools 0.9.10 and enabling features :formatters :hints :async
util.js:92 Uncaught TypeError: Cannot read property 'contains' of undefined
at Object.goog.labs.userAgent.util.matchUserAgent (util.js:92)
at Object.goog.labs.userAgent.browser.matchChrome_ (browser.js:125)
at devtools$formatters$available_QMARK_ (formatters.cljs:17)
at devtools$core$is_feature_available_QMARK_ (core.cljs:17)
at util.cljs:246
at Object.devtools$util$install_feature_BANG_ [as install_feature_BANG_] (util.cljs:246)
at Function.cljs$core$IFn$_invoke$arity$1 (core.cljs:51)
at Function.cljs$core$IFn$_invoke$arity$0 (core.cljs:44)
at preload.cljs:11
goog.labs.userAgent.util.matchUserAgent @ util.js:92
goog.labs.userAgent.browser.matchChrome_ @ browser.js:125
devtools$formatters$available_QMARK_ @ formatters.cljs:17
devtools$core$is_feature_available_QMARK_ @ core.cljs:17
(anonymous) @ util.cljs:246
devtools$util$install_feature_BANG_ @ util.cljs:246
(anonymous) @ core.cljs:51
(anonymous) @ core.cljs:44
(anonymous) @ preload.cljs:11
browserevent.js:248 Uncaught TypeError: goog.debug.freeze is not a function
at browserevent.js:248
(anonymous) @ browserevent.js:248
string.cljs:227 Uncaught TypeError: goog.string.isEmptySafe is not a function
at Object.clojure$string$blank_QMARK_ [as blank_QMARK_] (string.cljs:227)
at Object.cljs$spec$alpha$fn_sym [as fn_sym] (alpha.cljs:124)
at alpha.cljs:154
at Function.G__50065__1 [as cljs$core$IFn$_invoke$arity$1] (alpha.cljs:154)
at Function.cljs$core$IFn$_invoke$arity$1 (alpha.cljs:132)
at Function.cljs$core$IFn$_invoke$arity$1 (alpha.cljs:160)
at Object.cljs$spec$alpha$with_gen [as with_gen] (alpha.cljs:217)
at primitives.cljc:497
also its complaining about not finding functions that I'm sure are there
Itried cleaning .shadow-cljs and the outputs, but the problem persist, so weird, I just reverted 😛
the shadow version, to get the charset working
setting it to ascii then produces /** @private @type {string} */ goog.i18n.bidi.ltrChars_ = "A-Za-z\u00c0-\u00d6\u00d8-\u00f6\u00f8-
which looks better
I'm trying cleaning the node modules, maybe something got bad there
I experienced this when I switching between shadow-cljs versions. you have to clean everything
@lilactown can you tell me exactly what everything is? I tried cleaning: node_modules
, .shadow-cljs
and build targets, but doesn't seem to fix
@wilkerlucio try 2.8.28
with :closure-output-charset "US-ASCII"
. that should now be properly applied everywhere
to fix the startsWith
error, I make sure that I clear:
- .shadow-cljs
- any build output
and rebuild. if that doesn’t work, do it a second time 😛
@thheller I'm right now with the bad setup going on, I was just updating to try the latest
but I can stay in the bad one if you wanna look at something
ok, let me just try rebuilding and check if the problem persist, not sure what my current output is about
the issue was in a workspaces build
not on the chrome ones
humm, I do actually, if they are from different projects they can still mess with each other?
meh, now the problem went away
my co-workers and I experienced the startsWith
error anytime we switched branches that used diff shadow-cljs versions (one 2.7.x, one 2.8.x)
I'm bumping to the latest again now to check the encoding thing
on the first run it get again the bad encoding, cleaning everything up and trying again
@thheller encoding issue seems to persist in 2.8.28
the compiled file still includes:
/** @private @type {string} */ goog.i18n.bidi.ltrChars_ = "A-Za-zÀ-ÖØ-öø-ʸ̀-ऀ-" + "Ⰰ-\ud801\ud804-\ud839\ud83c-\udbff" + "豈-︀--";
/** @private @type {string} */ goog.i18n.bidi.rtlChars_ = "֑-ۯۺ-ࣿ\ud802-\ud803\ud83a-\ud83b" + "יִ-﷿ﹰ-ﻼ";
/** @private @type {RegExp} */ goog.i18n.bidi.htmlSkipReg_ = /<[^>]*>|&[^;]+;/g
;you set :compiler-options {:closure-output-charset "US-ASCII"}
and do a clean compile
or whatever?
rm -rf .shadow-cljs/ shells/chrome/out/ shells/chrome/js/
and then compile
running one more time:
wilkerlucio:fulcro-inspect wilker.lucio$ rm -rf .shadow-cljs/ shells/chrome/out/ shells/chrome/js/
wilkerlucio:fulcro-inspect wilker.lucio$ npm run dev-chrome -- -A:local/pathom:local/pathom-viz
> [email protected] dev-chrome /Users/wilker.lucio/Development/third-part/fulcro-inspect
> shadow-cljs watch chrome-devtool chrome workspaces "-A:local/pathom:local/pathom-viz"
shadow-cljs - config: /Users/wilker.lucio/Development/third-part/fulcro-inspect/shadow-cljs.edn cli version: 2.8.28 node: v11.10.0
shadow-cljs - starting via "clojure"
shadow-cljs - HTTP server available at
shadow-cljs - server version: 2.8.28 running at
shadow-cljs - nREPL server started on port 63104
shadow-cljs - watching build :chrome-devtool
shadow-cljs - watching build :chrome
shadow-cljs - watching build :workspaces
same thing
I'll try again, killing any shadow instance running before doing it again
yeah, but at master
and maybe I have uncommited things
let me check
ok, if you go to branch index-explorer
now it will be a mirror of what I have
ups, pushing
ok, now pushed
Error building classpath. Could not find artifact com.wsscode:pathom:jar:2.2.13 in central ( )
org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact com.wsscode:pathom:jar:2.2.13 in central ( )
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:422)
ups, sorry, a little messy deps at this moment, but you dont actually need this to build I guess, try going 2.2.12 and see if it works
Error building classpath. Could not find artifact com.wsscode:pathom-viz:jar:1.0.5 in central ( )
org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact com.wsscode:pathom-viz:jar:1.0.5 in central ( )
hahaha, that's why you saw my aliases XD
humm, maybe we can just try master bumping shadow? those encoding things I believe are not new
[:chrome-devtool] Build failure:
The required namespace "com.wsscode.pathom.viz.index-explorer" is not available, it was required by "fulcro/inspect/ui_parser.cljs".
[:workspaces] Build failure:
The required namespace "com.wsscode.pathom.viz.index-explorer" is not available, it was required by "fulcro/inspect/ui_parser.cljs".
yeah, master should not have index-explorer, that's the new thing I'm working on
@thheller just got myself back on that that startsWith
issues again
there is cljs-runtime/goog.string.string.js
, that contains things
/** @private @type {string} */ goog.i18n.bidi.ltrChars_ = "A-Za-z\u00c0-\u00d6\u00d8-\u00f6\u00f8-\u02b8\u0300-\u0590\u0900-\u1fff" + "\u200e\u2c00-\ud801\ud804-\ud839\ud83c-\udbff" + "\uf900-\ufb1c\ufe00-\ufe6f\ufefd-\uffff"
full build with errors: https://www.dropbox.com/s/a02izgbu4zuq31e/workspaces.zip?dl=0
strange, just didn't worked for me, it keeps compiling with the utf chars
I can try to do on master
maybe something got affected by the new things
lets do this, I'll get myself back to 2.7.6 so I can continue working, because I'm in the middle of trying to release 3 things at once that depend on each other
once those are out we can have a simpler way to reproduce the setup
I just noticed I wasn't cleaning the output folder for the workspaces build
seems to work fine rebuilding after cleaning that up
since the goog.string.internal.js
file definitely exists. the main.js
just isn't loading it
what you think about having a shadow-cljs cleanup
command?
I ask because I found myself frequently missing one or other folder
shadow could use the build info to delete everything without missing
I'd rather have it in a place where that is never necessary and the build just does the correct thing
yeah, just so tempting to have it, hehe
but I agree, having it will reduces the chance of an actual fix
yeah but then it ends up like it does in lein
where the first question always is did you run lein clean
?
I can't see how main.js
gets outdated with what is in cljs-runtime
since it is written after those files are written
considering that was a minor version change, which means google closure changes, many of those out of your control, what if we detected the version change and auto-clean when that happens?
humm, but this seems like some closure dep got missing in the process, as I understand those separated files are still used in the dev runs, irhgt?
SHADOW_ENV.load({}, ["goog.debug.error.js","goog.dom.nodetype.js","goog.string.string.js",
SHADOW_ENV.load({}, ["goog.debug.error.js","goog.dom.nodetype.js","goog.asserts.asserts.js","goog.reflect.reflect.js","goog.math.long.js","goog.math.integer.js","goog.string.internal.js","goog.string.string.js"
considering this is happening when I'm rolling back, maybe it was a bug from that version you already fixed?
this is the last time that part of the code changed https://github.com/thheller/shadow-cljs/commit/8ee74c5cf2d88f0236bd6d8be2ba1ceb98d04f3b
you think using of local alias deps might be having something to do with it?
no, I don't have that open
at most maybe intellij is trying to read it in background
nope, no container or anything like that
just local ssd drive, io issues should be at minimum
hmm not at all .. so you should at least be getting an exception if it fails to write
@wilkerlucio does the encoding thing at least work now?
in 2.7.6 it always had worked for me, I'm sticking to this version for now
thanks for hanging on the debugging
just for sanity's sake check if you maybe have an old JVM process lingering on somewhere in the background
one long forgotten process just working along in the background would explain this behavior
I did checked for that, but no, I made sure that was no shadow process running before starting the compilation
Okay, with your help I was able to fix the original library.
It does gets me that the library is originally using lein-cljsbuild
, and it does compile there. Is shadow-cljs stricter than lein-cljsbuild?