Fork me on GitHub
#shadow-cljs
<
2019-04-07
>
orestis05:04:30

You might need to look into either polyfills or es3

orestis05:04:49

Not sure if these versions of safari support es5 (they should)

thheller08:04:52

@caleb.macdonaldblack what kind of compatibility issues?

caleb.macdonaldblack08:04:46

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.

thheller08:04:26

if you tell me exactly which errors you get I can maybe tell you how to fix them

thheller08:04:57

eg. are the errors occuring in CLJS code or in some imported npm libs?

caleb.macdonaldblack09:04:45

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.

thheller09:04:30

yeah its probably the npm libs then

thheller09:04:04

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

caleb.macdonaldblack09:04:27

Is that done using :prepend as mentioned in the issue that orestis linked?

thheller09:04:44

no, see my last comment.

thheller09:04:06

> :compiler-options {:rewrite-polyfills true :output-feature-set :es3

caleb.macdonaldblack09:04:46

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.

thheller09:04:53

polyfill detection in npm code is not as reliable as I'd like it to be so it might not work

caleb.macdonaldblack09:04:05

Nah that didn't work for me sorry.

caleb.macdonaldblack09:04:31

forgive me sending the screenshot. I'm using a browserStack vm

thheller09:04:32

ok yeah thats a bug then. it is supposed to detect the polyfills properly and Object.assign is definitely one of them

caleb.macdonaldblack09:04:44

I posted my shadow-cljs.edn just to rule out any mistakes I may have made setting those compiler options

caleb.macdonaldblack09:04:05

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

caleb.macdonaldblack09:04:43

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

thheller09:04:50

I'll see if I can figure it out.

caleb.macdonaldblack09:04:28

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

thheller09:04:44

yeah thats not available as a polyfill (in closure)

thheller09:04:50

do the errors happen directly on load or do you need to call something specific first?

caleb.macdonaldblack23:04:33

On load I believe. I still get the error after omitting the .init() call.

thheller10:04:40

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

thheller10:04:14

that should take care of all polyfill issues

caleb.macdonaldblack23:04:54

Amazing! Thank you so much

caleb.macdonaldblack08:04:07

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.

caleb.macdonaldblack08:04:57

And I've updated shadow-cljs to the new version aswell

thheller08:04:02

you shouldn't need the :compiler-options

caleb.macdonaldblack08:04:28

I did try without that also and had the same effect

thheller08:04:49

how big is the .shadow-cljs/babel-worker/babel-worker.js file?

caleb.macdonaldblack08:04:37

there is no babel-worker directory

thheller08:04:20

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

mauricio.szabo15:04:39

Is there any reason that newer versions o Shadow-CLJS are not printing the socker REPL port on start, only the nREPL?

thheller15:04:35

no specific reason other than I wanted to reduce the amount of "spam" at the start

thheller15:04:49

would have removed the nrepl message but cider is looking for it still 😞

thheller15:04:30

if you need to know the port you can either configure a fixed port or look at the .shadow-cljs/socket-repl.port file

mauricio.szabo15:04:39

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?

thheller15:04:00

not sure how those are related?

mauricio.szabo15:04:11

No, they are not, sorry 🙂

thheller15:04:43

sounds like you are maybe using cljs.test in clojure?

mauricio.szabo15:04:42

No, this is a test namespace only for ClojureScript

thheller15:04:35

can you paste some code?

thheller15:04:48

and the actual error you get?

mauricio.szabo15:04:53

(ns paprika.collection-test
  (:require [clojure.test :refer [deftest testing is assert-expr] :include-macros true]
            [paprika.collection :as coll]))

mauricio.szabo15:04:07

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 | 

mauricio.szabo15:04:28

cli version: 2.8.26 node: v10.6.0

thheller15:04:39

why do you :refer that?

mauricio.szabo15:04:22

This library here uses assert-expr to extend clojure.test: https://github.com/nubank/matcher-combinators

mauricio.szabo15:04:50

And I was getting this error while trying to use it on shadow-cljs, and then I tried to fix this bug

thheller15:04:14

it does exist so the error is definitely weird

mauricio.szabo15:04:36

I'll try to test on other targets and if it works, should I open an issue?

thheller15:04:03

I can reproduce it with any build yes

thheller15:04:13

looking into why

thheller15:04:39

@mauricio.szabo that function is only used by macros so it must be implemented in CLJ

thheller15:04:25

cljs/test.cljs exists as well as cljs/test.cljc

thheller15:04:44

so the CLJS side uses cljs/test.cljs and imports cljs/test.cljc as macros

thheller15:04:04

so the CLJS side only sees cljs/test.cljs + the macros defined in cljs/test.cljc

thheller15:04:23

since assert-expr is not a macro its not visible as it wouldn't be usable anyways

thheller15:04:35

you can still extend it on the CLJ side of things

thheller15:04:39

just not directly in CLJS

thheller15:04:47

so this is working as expected

thheller15:04:06

gets me every time 😛

mauricio.szabo17:04:52

Thanks for the help!

mauricio.szabo00:04:45

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?

thheller10:04:51

IIRC nubank had a couple other projects that were written in CLJC but never really used from CLJS

thheller10:04:21

but yeah the default cljs compiler is sometimes a little less strict and lets some things pass without verifying

👍 4
wilkerlucio16:04:22

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?

thheller16:04:18

@wilkerlucio what is this orginially? import * as d3 from "/node_modules/d3/dist/d3.node.js"; just import ... from "d3";?

wilkerlucio16:04:47

its: import * as d3 from "d3";

thheller16:04:19

the easy fix is probably not using ESM import/export but rather write it in commonjs

thheller16:04:36

closure changed a bunch of stuff recently and I guess has problems with this now

thheller16:04:41

I'll try to figure out why

wilkerlucio16:04:12

you mean switch to require and module.exports?

thheller16:04:30

I'm doing something related right now anyways so I'll check out whats happening

wilkerlucio16:04:06

thanks, I'll try replacing and see how it goes

thheller16:04:10

ah it might be my incremental compilation

thheller16:04:53

yeah, found it

thheller16:04:33

it all works fine when compiling from scratch but incremental compilation is busted

thheller16:04:56

guess the faking I did to make that work doesn't work anymore 🙂

thheller16:04:33

@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

thheller16:04:43

keeps changing constantly

wilkerlucio17:04:08

@thheller awesome, just confirmed it fixed the build 👍

wilkerlucio17:04:14

@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

wilkerlucio17:04:30

is that a setting I can change to force utf-8 for everything?

wilkerlucio17:04:09

nevermind, seems some transient issue, disabling and reenabling the extension got it back :man-shrugging:

thheller17:04:32

weird indeed

thheller17:04:48

it is utf-8 for everything by defualt

wilkerlucio20:04:43

@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

thheller20:04:01

you can set :compiler-options {:closure-output-charset "ASCII"} but that defaults to utf-8 so no idea why it would complain

thheller20:04:49

in normal browser things that is fixed by adding the <meta charset="utf-8"> or content-type header

thheller20:04:07

things certainly haven't changed in this regard for a very long time

wilkerlucio21:04:08

no lucky here, it keeps complaining about that bidi i18n file -.-

wilkerlucio21:04:24

I was already using :compiler-options {:closure-output-charset "US-ASCII"} before

wilkerlucio21:04:33

I tried now removing, using just ASCII, but none worked

wilkerlucio21:04:18

I can confirm it gets back working when I reverted shadow to version 2.7.6

wilkerlucio21:04:57

I can try finding the version that introduced the problem, you think that might be due to some change in closure or maybe cljs?

thheller21:04:13

it probably isn't the shadow-cljs version, only the bumped closure-compiler version

thheller21:04:14

$ 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

thheller21:04:27

can you check your file?

thheller21:04:20

when I open the file it does indeed look messed up though

wilkerlucio21:04:14

I opened here, the file looked fine and in utf-8 :thinking_face:

wilkerlucio21:04:40

but now for some reason with the reversed version I'm getting a lot of weird bad things happening...

thheller21:04:52

/** @private @type {string} */ goog.i18n.bidi.ltrChars_ = "A-Za-zÀ-ÖØ-öø-ʸ̀-֐ऀ-῿"

thheller21:04:54

this looks broken

wilkerlucio21:04:17

I have that here too

wilkerlucio21:04:42

have you seen something like this? after reverting the version I'm getting all sorts of errors that I never saw before:

wilkerlucio21:04:43

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

wilkerlucio21:04:59

also its complaining about not finding functions that I'm sure are there

wilkerlucio21:04:15

Itried cleaning .shadow-cljs and the outputs, but the problem persist, so weird, I just reverted 😛

thheller21:04:47

reverted what?

thheller21:04:15

I found one problem with the output-charset in that it didn't apply in dev builds

wilkerlucio21:04:37

the shadow version, to get the charset working

thheller21:04:44

setting it to ascii then produces /** @private @type {string} */ goog.i18n.bidi.ltrChars_ = "A-Za-z\u00c0-\u00d6\u00d8-\u00f6\u00f8- which looks better

wilkerlucio21:04:46

I'm trying cleaning the node modules, maybe something got bad there

lilactown21:04:26

I experienced this when I switching between shadow-cljs versions. you have to clean everything

lilactown21:04:45

specifically between 2.7 and 2.8 which upped the closure version

thheller21:04:49

why is nobody telling me that? 😛

lilactown21:04:25

haha 😅 sorry, it’s hard sometimes when I’m dealing with stuff at work all day

wilkerlucio21:04:36

@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

thheller21:04:09

@wilkerlucio try 2.8.28 with :closure-output-charset "US-ASCII". that should now be properly applied everywhere

👀 4
thheller21:04:20

previously it only applied to release builds

lilactown21:04:20

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 😛

thheller21:04:21

if you run into this again. PLEASE DO NOT DELETE ANYTHING!

thheller21:04:38

makes it impossible to figure out what is happening

thheller21:04:49

do you still have the broken state?

wilkerlucio21:04:58

@thheller I'm right now with the bad setup going on, I was just updating to try the latest

lilactown21:04:08

my hypothesis is that it’s diff versions of closure lying around between builds

wilkerlucio21:04:10

but I can stay in the bad one if you wanna look at something

thheller21:04:39

alright. can you zip up your cljs-runtime dir of that build and send it to me?

thheller21:04:11

ah wait crap its chrome extension

wilkerlucio21:04:12

ok, let me just try rebuilding and check if the problem persist, not sure what my current output is about

wilkerlucio21:04:22

the issue was in a workspaces build

wilkerlucio21:04:27

not on the chrome ones

thheller21:04:02

the only real guess I have is that you still have a shadow-cljs instance running

thheller21:04:30

running two processes at the same time causes problems

wilkerlucio21:04:34

humm, I do actually, if they are from different projects they can still mess with each other?

thheller21:04:40

hmm no thats fine

thheller21:04:52

just two processes writing the same output-dir causes problems

wilkerlucio21:04:14

meh, now the problem went away

lilactown21:04:31

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)

wilkerlucio21:04:32

I'm bumping to the latest again now to check the encoding thing

wilkerlucio21:04:25

on the first run it get again the bad encoding, cleaning everything up and trying again

wilkerlucio21:04:26

@thheller encoding issue seems to persist in 2.8.28

thheller21:04:40

did you try wiping the output dir?

wilkerlucio21:04:04

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
;

thheller21:04:07

you set :compiler-options {:closure-output-charset "US-ASCII"} and do a clean compile or whatever?

thheller21:04:21

that is definitely not the output produced if US-ASCII is set

wilkerlucio21:04:28

rm -rf .shadow-cljs/ shells/chrome/out/ shells/chrome/js/ and then compile

thheller21:04:37

did you check that the correct version is used on startup?

wilkerlucio21:04:58

running one more time:

wilkerlucio21:04:02

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

thheller21:04:19

shadow-cljs - server version: 2.8.28 running at ?

thheller21:04:38

need to check the server version. cli version doesn't mean anything really.

thheller22:04:09

this is the repo right?

wilkerlucio22:04:09

I'll try again, killing any shadow instance running before doing it again

wilkerlucio22:04:15

yeah, but at master

wilkerlucio22:04:20

and maybe I have uncommited things

wilkerlucio22:04:07

ok, if you go to branch index-explorer now it will be a mirror of what I have

wilkerlucio22:04:53

ok, now pushed

thheller22:04:39

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)

wilkerlucio22:04:18

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

thheller22:04:01

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 ()

wilkerlucio22:04:13

hahaha, that's why you saw my aliases XD

wilkerlucio22:04:40

humm, maybe we can just try master bumping shadow? those encoding things I believe are not new

thheller22:04:05

[: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".

wilkerlucio22:04:28

yeah, master should not have index-explorer, that's the new thing I'm working on

thheller22:04:08

I think I know whats happening. just a sec to confirm

thheller22:04:25

hmm nope all good

wilkerlucio22:04:26

@thheller just got myself back on that that startsWith issues again

thheller22:04:21

ok please check the cljs-runtime/goog.string.js file? is it empty?

wilkerlucio22:04:08

there is cljs-runtime/goog.string.string.js, that contains things

thheller22:04:34

/** @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"

thheller22:04:57

this is in the goog.i18n.bidi.js I get when I bump fulcro-inspect master to 2.8.28

thheller22:04:15

so US-ASCII is doing what it should?

wilkerlucio22:04:37

strange, just didn't worked for me, it keeps compiling with the utf chars

wilkerlucio22:04:45

I can try to do on master

wilkerlucio22:04:52

maybe something got affected by the new things

wilkerlucio22:04:59

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

wilkerlucio22:04:11

once those are out we can have a simpler way to reproduce the setup

thheller22:04:56

yeah I'll see if I can figure it out with the files you sent me

thheller22:04:57

ok what the heck

thheller22:04:05

for some reason the goog.string.internal ns is just missing

wilkerlucio22:04:13

I just noticed I wasn't cleaning the output folder for the workspaces build

wilkerlucio22:04:22

seems to work fine rebuilding after cleaning that up

thheller22:04:46

that would make sense if the main.js is just outdated

thheller22:04:05

since the goog.string.internal.js file definitely exists. the main.js just isn't loading it

thheller22:04:31

I can't see how that would happen other than main.js not getting written properly

wilkerlucio22:04:44

what you think about having a shadow-cljs cleanup command?

wilkerlucio22:04:59

I ask because I found myself frequently missing one or other folder

wilkerlucio22:04:09

shadow could use the build info to delete everything without missing

thheller22:04:38

I'd rather have it in a place where that is never necessary and the build just does the correct thing

wilkerlucio22:04:52

yeah, just so tempting to have it, hehe

wilkerlucio22:04:01

but I agree, having it will reduces the chance of an actual fix

thheller22:04:20

yeah but then it ends up like it does in lein where the first question always is did you run lein clean?

thheller22:04:26

I don't want to get to that point

thheller22:04:30

I'd rather fix the bugs ...

thheller22:04:07

I might be dropping some exceptions if the file maybe fails to write?

thheller22:04:35

I can't see how main.js gets outdated with what is in cljs-runtime since it is written after those files are written

thheller22:04:47

that doesn't make sense to me

thheller22:04:03

its also always getting written. that file is never cached

wilkerlucio22:04:20

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?

thheller22:04:47

like I said .. there is nothing to clean

thheller22:04:14

main.js is always written, blindly .. there is no check if it exists or not

thheller22:04:32

the other files check if they exist and are newer than the source

thheller22:04:54

changing dependencies ensures that they are written again

wilkerlucio22:04:58

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?

thheller22:04:09

no the file isn't missing

thheller22:04:12

the file exists

thheller22:04:20

it just isn't getting loaded at all

thheller22:04:27

SHADOW_ENV.load({}, ["goog.debug.error.js","goog.dom.nodetype.js","goog.string.string.js",

thheller22:04:34

last line in main.js

thheller22:04:46

that is not the correct file order

thheller22:04:53

it looks outdated

thheller22:04:20

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"

thheller22:04:25

this is what I get when I compile

thheller22:04:33

not the internal.js loading before string.js

thheller22:04:01

so your main.js just looks outdated. I just don't know how that could happen

wilkerlucio22:04:00

considering this is happening when I'm rolling back, maybe it was a bug from that version you already fixed?

thheller22:04:16

so nothing has changed there for a long time and definitely not since 2.7.x

thheller22:04:49

this was 2.3.x era or so

thheller22:04:41

it also is compiling completely find on my machine (your fulcro-inspect master)

thheller22:04:46

so I have no clue whats happening

thheller22:04:30

do you maybe have the main.js file open in an editor?

thheller22:04:46

shadow-cljs writes the new one, editor overwrites it with the state it has?

wilkerlucio22:04:47

you think using of local alias deps might be having something to do with it?

wilkerlucio22:04:04

no, I don't have that open

wilkerlucio22:04:16

at most maybe intellij is trying to read it in background

thheller22:04:01

is this running in a container or so? network drive?

thheller22:04:16

anything weird where things aren't written directly to disk?

wilkerlucio22:04:03

nope, no container or anything like that

wilkerlucio22:04:21

just local ssd drive, io issues should be at minimum

thheller22:04:27

I'm out of ideas. I have never seen this.

thheller22:04:35

let me check how spit deals with exceptions

thheller22:04:08

hmm not at all .. so you should at least be getting an exception if it fails to write

thheller22:04:15

@wilkerlucio does the encoding thing at least work now?

wilkerlucio22:04:52

in 2.7.6 it always had worked for me, I'm sticking to this version for now

wilkerlucio22:04:26

thanks for hanging on the debugging

thheller23:04:58

just for sanity's sake check if you maybe have an old JVM process lingering on somewhere in the background

thheller23:04:31

one long forgotten process just working along in the background would explain this behavior

wilkerlucio23:04:21

I did checked for that, but no, I made sure that was no shadow process running before starting the compilation

mauricio.szabo00:04:45

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?