Fork me on GitHub
#shadow-cljs
<
2020-09-01
>
timrichardt08:09:50

After 2.11.0 the default imports inside .js are kinda weird now? If i

import Card from "@material-ui/core/Card";
I now only can use it via
<Card.default> ... </Card.default>
The
import { foo } from "bar"
imports work as expected.

thheller08:09:52

@timrichardt unfortunately that is the only way I can make it work. closure is kinda strict about commonjs <-> ESM interop and as far as Closure is concerned it only sees the npm packages as commonjs

thheller08:09:15

did you not have issues with JS code in release prior to 2.11.0?

timrichardt08:09:43

I did, but this works now, as you intended.

thheller09:09:24

I wonder whats going to happen with webpack5. they've been talking about breaking changes in this area for years

thheller09:09:49

https://github.com/webpack/webpack/issues/11406 looks like its going to happen soon. hope it'll improve the situation a bit

dazld13:09:58

tap> is super handy! is there any way to be able to send stuff from a server side process to the inspect tab via the same helper..?

Lucy Wang14:09:54

not sure if possible, but for a pretty good general REBL-like solution, checkout https://github.com/djblue/portal

👍 6
pithyless10:09:34

@dazld I do just that, by starting a second shadow-cljs instance on the server-side. If you're running some kind of component system, you can hook up as just another start/stop component 🙂

pithyless10:09:28

(:require [shadow.cljs.devtools.server :as shadow-server])

(defn start-shadow-inspect []
  (println "Starting shadow-server...")
  (shadow-server/start!))
^ It will find an open port and print on what port it started.

thheller15:09:52

@dazld tap> for CLJ currently only works in the process where shadow-cljs is running. remote otherwise only works for CLJS.

👍 3
scottlowe18:09:10

I'm getting a security notification for the NPM lib Elliptic which needs to be bumped from 6.5.1 to 6.5.3. The dependency is only local but it's being included by shadow-cljs as a dependency of node-libs-browser. https://github.com/advisories/GHSA-vh7m-p724-62c2

scottlowe18:09:21

I was simply going to wait until shadow-cljs gets updated, but I've just noticed that node-libs-browser is deprecated and unlikely to be updated. Should I simply patch my yarn.lock file with a new elliptic version, or are there any plans for shadow-cljs that will sidestep this issue in the near future?

scottlowe18:09:03

elliptic module in shadow-cljs dependency tree

thheller18:09:15

I don't know what is going to happen with node-libs-browser once webpack v5 is out

thheller18:09:05

you can just bump the dependency in your project if you are worried but it isn't really relevant and this will only ever be used in browser builds

thheller18:09:26

which are probably safe. don't see how one could ever exploit this.

scottlowe18:09:03

Okay, thanks @thheller That's what I was thinking. It's only used in dev, obviously. Thanks! 🙇

thheller18:09:37

no its used in production BUT node-libs-browser are polyfills for npm built-in packages

scottlowe18:09:01

Ach. Right. Thanks for the correction.

thheller18:09:23

so you have to use a npm package that uses any of these. I'm assuming its require("crypto") and then use this in a browser (as :node-script etc will not use node-libs-browser)

thheller18:09:15

I can bump the node-libs-browser dep. maybe thats enough.

scottlowe18:09:25

I see what you mean. The version restrictions on crypto-browserify are relaxed for the minor version; so the child dependencies can be updated, even if there isn't a new release of node-libs-browser.

scottlowe18:09:58

Oh. That works for me locally too with yarn upgrade. I now have [email protected]. The joys of semantic versioning (seriously). The version restrictions were loose enough in shadow-cljs deps that I received the updated child packages. Well that's solved my problem 😊