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.@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
did you not have issues with JS code in release prior to 2.11.0?
I did, but this works now, as you intended.
Thx. 🙂
I wonder whats going to happen with webpack5. they've been talking about breaking changes in this area for years
https://github.com/webpack/webpack/issues/11406 looks like its going to happen soon. hope it'll improve the situation a bit
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..?
@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 🙂
(: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.not sure if possible, but for a pretty good general REBL-like solution, checkout https://github.com/djblue/portal
@dazld tap> for CLJ currently only works in the process where shadow-cljs is running. remote otherwise only works for CLJS.
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
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?
elliptic module in shadow-cljs dependency tree
I don't know what is going to happen with node-libs-browser once webpack v5 is out
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
which are probably safe. don't see how one could ever exploit this.
Okay, thanks @thheller That's what I was thinking. It's only used in dev, obviously. Thanks! 🙇
no its used in production BUT node-libs-browser are polyfills for npm built-in packages
Ach. Right. Thanks for the correction.
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
)
I can bump the node-libs-browser dep. maybe thats enough.
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
.
Oh. That works for me locally too with yarn upgrade
. I now have elliptic@6.5.3
. 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 😊