This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-26
Channels
- # announcements (18)
- # aws (17)
- # babashka (19)
- # beginners (141)
- # calva (73)
- # cider (4)
- # clj-kondo (13)
- # cljs-dev (2)
- # clojure (97)
- # clojure-europe (6)
- # clojure-italy (5)
- # clojure-nl (1)
- # clojure-spec (25)
- # clojure-sweden (2)
- # clojure-uk (25)
- # clojured (3)
- # clojurescript (63)
- # core-typed (6)
- # cursive (23)
- # data-science (4)
- # datomic (74)
- # fulcro (19)
- # graalvm (18)
- # graphql (3)
- # hoplon (63)
- # jackdaw (1)
- # juxt (23)
- # london-clojurians (3)
- # meander (7)
- # off-topic (23)
- # om (1)
- # pathom (13)
- # pedestal (2)
- # perun (2)
- # re-frame (38)
- # reagent (3)
- # reitit (24)
- # shadow-cljs (91)
- # spacemacs (14)
- # sql (4)
- # tools-deps (8)
- # vim (3)
related to requiring js files. now the js file wants to import stuff from the npm module that I've already required via shadow. How do I refer to it? as is, I get 'Cannot access "../../../build/three.module.js" from "jsm/misc/Ocean.js".' which makes a lot of sense. I suppose I could point :source-paths to the whole node-modules but it kind of defeats the purpose
I've fiddled around a lot with cljs + three.js. if you can give me a repro-repo I can help you 🙂
thanks @UCG86LJFN this is not open source at the moment. anyway, you might be able to help me with it. Able to fix the files in /jsm to require three as a module instead of path, but they also import a lot of stuff from three that now hasn't been exported. How do I resolve that, any idea?
just for completeness, the issue was that shadow compiler doesn't ES6 style module imports, i.e.
import {
Vector2
} from "three";
instead, I had to write it like this:
import * as three from 'three';
const { Vector2 } = three;
seems strange to me. I've been able to do import { Vector2 } from "three"
. either way, nice that you fixed it 🙂
I’d like to run /just/ the hot-reload and CLJS REPL parts of shadow-cljs, without exposing my computer’s clj-eval/etc. through the websocket to anyone passing by. I’ve been live editing my app in front of astonished (local network) users using shadow for some time now. Unfortunately, I can’t leave it running unsupervised or :gasp: expose it on the web, since the websocket/dashboard has clj-eval functionality, which opens up my computer to having arbitrary code run on it. If I’ve missed how to do this I’d love to hear about it — or if it’s not possible, I’d love to add support for it (perhaps whitelisting :supported_ops / :op ?)
sorry if this is a dumb question, if it is listening on localhost rather than 0.0.0.0 how is it being exposed ?
@thheller my hope /was/ to run it in a way that’s accessible to multiple folks and keep running it for a while, so that it hot reloads for all of them. That is — I’d like to expose the hot reload and CLJS REPL aspects without the ‘run code on my machine.’ aspects. My suggested thought was to filter the operations that can be sent over the websocket, so as not to include :clj-eval/etc. Does that make sense?
I think I may add a basic "trusted" check. so that some operation are only allowed from trusted clients. basically an IP check. defaulting to local only but maybe letting you add IPs via config
Mm, honestly even just having a configuration flag to turn off all of the ‘trusted’ operations would be super welcome.
But IP whitelisting would make it super effective (again, just across all trusted ops) — I could still get in to debug but allow others to see and hot reload it.
for what it's worth, I set up the combination of:
• Port forwarding 3000 -> 443 & 9630 to a domain
• SSL with a keystore + {:closure-defines {shadow.cljs.devtools.client.env.ssl true}}
and then was able to send folks to https://test-app.example.com and have them see my changes from wherever they were in real-time and debug their issues from the REPL (or the browser view, or even tap>
from the clients and Inspect the results).
It has made for a really interesting and capable development experience -- if the 'trusted/unsafe' operations could be IP whitelisted as you suggest, I would recommend this to most folks and see if I could bottle up the pattern and write something about it. :)
well as soon as you port forword the IP check will fail because the IP will be whatever does the tunneling 😛
Haha I did think of that and wonder (given that your TCP termination would be local) — and then wrote it off without considering further.
nah the secret is just a basic check so that you can't open the websocket without opening the UI first
I guess I could kill the HTTP side of the channel and only allow HTTP 101 to secure it 😂 — though I suspect it’s sent early :P
first of all you need to separate what you want to allow access to in the first place
And the runtime has hot reload and the connection to the relay for cljs REPL into those clients IIUC
@kaosko you just need to rewrite the require in those files to use the regular threejs from npm, ie. not a path
hello channel. thanks for shadow-cljs - i'm just getting started and trying to understand if I am working with shadow-cljs correctly. I have a shadow-server setup and shadow is watching my :app for a :browser target. I can connect in the browser, etc and my app works there without errors. I am using vim-fireplace to connect to the nREPL and edit code, etc. One thing I cannot get working is omni-completion for npm modules that shadow-cljs is handling.
For example, in one file i have a (:require such as ["@material-ui/core" :as mui]. I cannot get omni-complete to complete anything after mui/ namespace
its used to tell you what is defined in a namespace on the fly (based on what you're typing)
hmm ok. I should probably do a bit more thinking about the problem and digging into source. I used to have completion working (for example with material-ui) but that was using a cljsjs module where each export from the node module was explicitly defined in cljs
so what do people think. would your development setup be broken if it defaulted to localhost
only? https://github.com/thheller/shadow-cljs/issues/660
given the fact that all human friendly distro default /etc/hosts to forward to localhost, then I wouldn't worry about defaulting to it. The people that have changed it (hopefully) know what they are doing and I guess could configure their setup differently.
@thheller my hope /was/ to run it in a way that’s accessible to multiple folks and keep running it for a while, so that it hot reloads for all of them. That is — I’d like to expose the hot reload and CLJS REPL aspects without the ‘run code on my machine.’ aspects. My suggested thought was to filter the operations that can be sent over the websocket, so as not to include :clj-eval/etc. Does that make sense?
for what it's worth, I set up the combination of:
• Port forwarding 3000 -> 443 & 9630 to a domain
• SSL with a keystore + {:closure-defines {shadow.cljs.devtools.client.env.ssl true}}
and then was able to send folks to https://test-app.example.com and have them see my changes from wherever they were in real-time and debug their issues from the REPL (or the browser view, or even tap>
from the clients and Inspect the results).
It has made for a really interesting and capable development experience -- if the 'trusted/unsafe' operations could be IP whitelisted as you suggest, I would recommend this to most folks and see if I could bottle up the pattern and write something about it. :)
Hello, does anyone have a nice little template to write web extensions (for firefox and chrome) using shadow-cljs?
for chrome we have an example here, not sure if it is little or particulary nice tough 🙂
the :chrome-extension
target actually doesn't do anything chrome specific so it might work