I've read the relevant bits of the user guide, but I don't really understand how to set up CSS reloading. My CSS file is at resources/public/css/main.css, and my HTTP server serves it at /assets/css/main.css. What do I need to set as the values of :watch-dir and :watch-path so that CSS reloading works?

Hi guys, I'm experiencing constantly the REPL server crash after a while

$ shadow-cljs watch app
shadow-cljs - config: /path/to/shadow-cljs.edn  cli version: 2.8.61  node: v10.16.3
..... (after a while ) ....
[:app] Compiling ...
[:app] Build completed. (68 files, 1 compiled, 0 warnings, 0.04s)
shutting down ...
Worker shutdown.
Exception in thread "async-dispatch-7" java.lang.Error: java.net.SocketException: Socket closed
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1155)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.SocketException: Socket closed
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:118)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        at nrepl.transport$bencode$fn__5929.invoke(transport.clj:116)
        at nrepl.transport.FnTransport.send(transport.clj:41)
        at nrepl.middleware.print$send_nonstreamed.invokeStatic(print.clj:159)
        at nrepl.middleware.print$send_nonstreamed.invoke(print.clj:138)
        at nrepl.middleware.print$printing_transport$reify__6306.send(print.clj:174)
        at nrepl.middleware.caught$caught_transport$reify__6341.send(caught.clj:58)
        at shadow.cljs.devtools.server.nrepl_impl$send.invokeStatic(nrepl_impl.clj:32)
        at shadow.cljs.devtools.server.nrepl_impl$send.invoke(nrepl_impl.clj:19)
        at shadow.cljs.devtools.server.nrepl_impl$worker_exit.invokeStatic(nrepl_impl.clj:49)
        at shadow.cljs.devtools.server.nrepl_impl$worker_exit.invoke(nrepl_impl.clj:45)
        at shadow.cljs.devtools.server.nrepl_impl$repl_init$fn__6916$state_machine__2842__auto____6941$fn__6943.invoke(nrepl_impl.clj:207)
        at shadow.cljs.devtools.server.nrepl_impl$repl_init$fn__6916$state_machine__2842__auto____6941.invoke(nrepl_impl.clj:205)
        at clojure.core.async.impl.ioc_macros$run_state_machine.invokeStatic(ioc_macros.clj:973)
        at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:972)
        at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invokeStatic(ioc_macros.clj:977)
        at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:975)
        at clojure.core.async.impl.ioc_macros$take_BANG_$fn__2860.invoke(ioc_macros.clj:986)
        at clojure.core.async.impl.channels.ManyToManyChannel$fn__655.invoke(channels.clj:265)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        ... 2 more

I got this for both :target :node-script and :target :browser. The shadow-cljs watch app command is still running there though.

is this a known bug?

@wxitb2017 are you on OSX by any chance?

yeah!

hmm yeah multiple people have been reporting this on OSX. it seems like something in the OS is starting to kill the shadow-cljs process when it reaches a certain memory usage

you can set :jvm-opts ["-Xmx1G"] to limit it to 1gig of RAM (either in shadow-cljs.edn or project.clj in case you use lein)

that has fixed it for everyone so far

I still haven't figured out why it is getting killed by the OS

OSX + lein seems to be the most common setup where this happens

you can also assign less or more RAM. depends on how much your machine has I guess. would be interesting to find out when it starts crashing 😛

sure, I already applied the 1G limit and restarted it. Would report back if that helps. Thx a lot!

Does anyone know if there are docs for how to build the Shadow CLJS client-side code without optimizations? I’ve been trying to troubleshoot CSS reloading and was hoping to step through this code in the browser: - Source: https://github.com/thheller/shadow-cljs/blob/2.8.51/src/main/shadow/cljs/devtools/client/browser.cljs#L166-L199 which ends - In our app: /<CLOSURE_BASE_PATH>/shadow.cljs.devtools.client.browser.js My plan was to: - Clone the repo - Change the optimizations (???) - Run the “build all” script - Use npm link to use the <repoDir>/packages/shadow-cljs and shadow-cljs-jar packages in our app - Rebuild our app and step through the less minified code 🤞 Does that sound like it’d work?

@sean.poulter I'm confused. there are no optimizations applied in watch or compile builds? only release builds and those won't contains the client/browser.cljs?

It’s a watch build on the app end, yea.

I guess that means it’d have to be modified on our end. :thinking_face:

no, but I don't understand what you are actually trying to do

the steps you described wouldn't do anything

browser.cljs is compiled as part of your project

if you want to use the chrome debugger to debug something in it

open the "Sources" tab in the chrome devtools

select the /js/cljs-runtime/shadow/cljs/devtools/browser.cljs and set a breakpoint

you can just take the browser.cljs and add it into one of your :source-paths if you want to make modifications

I’ve got that far. It’s minified and a bit confusing without a source map.

thats not the .cljs file

it also isn't minified, it is compiled .js code

Thanks for correcting me on that, yes.

it should be showing those like this

there might be .js variant of that namespace and a .cljs variant

might be quicker if you just describe the problem you are seeing 😛

Ah. We must have source maps off. It’s a bit different on our end and just the compiled JS under (no domain):

Thanks for your patience with this. I’ve dropped into the Clojure world from JavaScript. 😓

it is normal that things might be listed twice

you can't even turn off source maps in development so unlikely they are off

@sean.poulter there isn't much to CSS reloading, it is watching a directory via either :watch-dir or the http root. lets say public. You have a public/css/foo.css. it will attempt to reload /css/foo.css. you can specify :watch-path "/x" which would make it try to reload /x/css/foo.css

So the watch-path is prepended to the link href?

it is prepending :watch-path to the PATH of the .css file it is trying to reload yes

but if the <link doesn't already use that path, it won't reload because it will think it is a different file

I'll give that a try. We're using a proxy to use local code against a prod backend which is at server.localhost:port/extra-path/css/foo.css.

I gave it a try and it didn't work, so I've gone down a rabbit hole trying to figure out why.

uhm how is CSS reloading going to work then?

it can't reload CSS from a different server?

("I gave it a try" meaning, trying to follow the docs with the watch dir and watch path not working.)

The JS hot reloads and its served from the same folder.

if you have <link rel="stylesheet" href=""> it is never going to reload that CSS

It's honestly quite confusing to me.

It's a <link href="/css/foo.css"/>.

ok. that should be fine then?

unless you proxy just proxies that directly to the other server?

Should be! Oooh. :thinking_face:

all CSS reloading does is perform the request again

It's loading our local CSS, just not reloading it.

Yea. So all of this is why I was trying to figure out how to step through where it's deciding it's not working.

Thanks so much for talking it through! I'll go dig into the watch-path and also figure out my source maps. :)

just don't look under (no domain)? I only have the .js files there too

but to repeat: you have <link href="/css/foo.css"/>. that means it will only reload files that have :watch-dir + /css/foo.css, so if :watch-dir "public" then public/css/foo.css

check the browser console if an actual request is triggered. you might just get the old css back from the server?

I'll report back when I figure it out. It worked beautify when I configured the example in the README to build to dist. It doesn't make the request or log to the console. From the compiled code it looked like it was a path problem.

you can watch the websocket messages in the chrome devtools

{:type :asset-watch, :updates #{"/css/foo.css"}}

if that path doesn't match your link path then nothing happens

@thheller is there a way to figure out how a particular thing is getting into the output? I’m working on native in a shared source project and react-dom keeps leaking in…really painful figuring out how

when I grep the output it isn’t obvious

some dump of the dep graph

@tony.kay the web UI has a thing. after you hit comile or watch there is a "Build Namespaces" select box

select any namespace and it'll tell you how it ended up in the build

the JS deps you'll find under shadow.js.shim.*

really need to make that interface better and create a REPL fn for it or so 😛

@thheller trying to import a custom class, getting a type error TypeError: Cannot read property 'prototype' of undefined

const { AuthenticationService, JWTStrategy } = require('@feathersjs/authentication');
const { OAuthStrategy } = require('@feathersjs/authentication-oauth');

class AzureB2CStrategy extends OAuthStrategy {
  constructor(...args) {super(...args);}
  authenticate({error}, params) {
    super.authenticate(error, params);
  }
}

module.exports = AzureB2CStrategy

Then in my require ["./azureb2c.js" :as AzureB2CStrategy]

look ok to me, did you check if your requires are correct?

OAuthStrategy might just be nil/undefined?

Yeah I was able to confirm this works ["@feathersjs/authentication-oauth" :as auth] then (def OAuthStrategy (obj/get auth "OAuthStrategy"))

is this node or the browser?

nodejs

did you try :compiler-options {:output-feature-set :es7}?

I think even :es8 might be fine for node

I’ll try with that again, I was using :es6

hmm no that wouldn't make a diff then

are you sure you are looking at the correct thing?

yeah the stack trace is pointing to the super in constructor

did you check the compiled output?

where should I look?

for node builds it is in .shadow-cljs/builds/<the-id>/dev/out/cljs-runtime/*.js

no cljs-runtime folder

I could be on an old version

no that hasn't changed in years

did you specify a custom :output-dir? or is it not :node-script?

for :npm-module its just your :output-dir

ah yes I did

thats not the js file?

the js file should start with module$...

the file you posted is the degree9.auth.azureb2c ns

oh ok

that doesn't look like :es6 output

oh wait .. that may have the same caching bug

try wiping the .shadow-cljs/builds cache

it may not invalidate properly if you change :output-feature-set?

kk i’ll try that

shadow$provide.module$degree9$auth$azureb2c = function(
  global,
  process,
  require,
  module,
  exports,
  shadow$shims
) {
  require("shadow.js.shim.module$$feathersjs$authentication");
  var OAuthStrategy = require("shadow.js.shim.module$$feathersjs$authentication_oauth")
    .OAuthStrategy;
  global = function(args) {
    for (
      var $jscomp$restParams = [], $jscomp$restIndex = 0;
      $jscomp$restIndex < arguments.length;
      ++$jscomp$restIndex
    )
      $jscomp$restParams[$jscomp$restIndex - 0] = arguments[$jscomp$restIndex];
    return (
      OAuthStrategy.apply(
        this,
        $jscomp.arrayFromIterable($jscomp$restParams)
      ) || this
    );
  };
  $jscomp.inherits(global, OAuthStrategy);
  global.prototype.authenticate = function($jscomp$destructuring$var2, params) {
    OAuthStrategy.prototype.authenticate.call(
      this,
      $jscomp$destructuring$var2.error,
      params
    );
  };
  module.exports = global;
};

thats the compiled code, definitely polyfilled which it shouldn't do when using :es6+

dunno which JS version added ...args, it node supports that natively bump it to whatever language version that is 😛

hmm no cache is definitely invalidated correctly if :output-feature-set changes

@thheller this is with es-next as output-feature-set

Same type error

So it seems that any use of super in my js files fails

Ok so it looks like the files are in TypeScript that I am trying to require via the JS, npm has the compiled js tho

@flyboarder I think you are just not doing the config properly? when I set :es6 I get

shadow$provide.module$demo$test = function(global, require, module, exports) {
  require("shadow.js.shim.module$$feathersjs$authentication");
  ({
    OAuthStrategy: global
  } = require("shadow.js.shim.module$$feathersjs$authentication_oauth"));
  class AzureB2CStrategy extends global {
    constructor(...args) {
      super(...args);
    }
    authenticate({ error }, params) {
      super.authenticate(error, params);
    }
  }
  module.exports = AzureB2CStrategy;
};
//# sourceMappingURL=module$demo$test.js.map

dunno how to check if that actually works but you are definitely not doing the config correctly if you still gets the transpiled version afterwards