This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-19
Channels
- # aleph (8)
- # announcements (43)
- # babashka (43)
- # beginners (62)
- # calva (8)
- # cider (27)
- # clj-kondo (18)
- # cljs-dev (25)
- # cljsrn (16)
- # clojure (51)
- # clojure-europe (6)
- # clojure-nl (14)
- # clojure-spec (7)
- # clojure-uk (39)
- # clojurescript (17)
- # cursive (9)
- # datascript (12)
- # datomic (16)
- # events (1)
- # fulcro (7)
- # funcool (1)
- # graalvm (2)
- # graphql (5)
- # jobs (1)
- # juxt (6)
- # kaocha (9)
- # leiningen (11)
- # luminus (1)
- # malli (1)
- # off-topic (80)
- # other-languages (2)
- # overtone (3)
- # pedestal (5)
- # quil (1)
- # re-frame (6)
- # reagent (1)
- # reitit (4)
- # rewrite-clj (5)
- # shadow-cljs (207)
- # spacemacs (1)
- # specter (4)
- # sql (1)
- # vim (14)
- # xtdb (7)
hmm also working fine on macOS. @tony.kay is there anything special in your setup? can you check if .shadow-cljs/cli.check
exists?
the node process will write a .shadow-cljs/cli.check
every 2sec and the JVM process will check it to see if it keeps getting updated
(solving a problem from a while ago that there would be zombie JVM processes if node got killed or exited)
I can check later..I’m cranking on something and just had to revert. Using straight deps.edn, and yarn for deps install
👋 Totally unrelated, but I listened to you on the defn podcast today. Hope you’re well. Loved your hobby project plans and curious if you’ve made any progress.
I’m well, but busy. Hobby project shaping up. Still building tools, networks, and a bit of a money buffer…but it is starting to take shape I think
just published [email protected]
... hope that variant is actually more reliable ... unless you are still on java 1.8 I guess 😛
Hey folks. Any tips on the best way to see test results in IntelliJ/Cursive (for a frontend ClojureScript project)? I’ve got the CI build running in one process, and karma started in the terminal. Thanks! Have a lovely day. 👍
@thheller I just shot two PRs for allowing more user configs in ~/.shadow-cljs/config.ed.
- https://github.com/thheller/shadow-cljs/pull/600 for custom :log
- https://github.com/thheller/shadow-cljs/pull/601 for custom :nrepl
PTAL.
btw what do you think about enabling travis/circle for the project? Even if I always test locally before submitting the patch, the green check mark would make me more confident about my PR 😄 (and I see there is already a circleci.yml file, so I guess it's just a matter of settings)
@thheller WDYT of setting up github actions instead of circle and testing across linux/osx/windows?
I could set that up for you if you're interested
it would be interesting to have some automated way that runs a "test" build for each new release
I have something similar happening
also don't know how to test stuff for real since most of the stuff breaking is either related to breaking JS deps or complicated watch stuff
in my case, releases are done automatically, and the release is tested if done
but I think a workflow can also be set that is triggered on tags
e.g. you make the release manually, then push the tag, then the workflow runs on the tag
I have some experience testing build tools... testing watch is really hard, but testing builds is easy as long as the build itself also contains an e2e
something like https://github.com/mfikes/patch-tender would also be nice
so those tests become something like "I want to test that these latest changes will still make the test-project e2e work", then have test projects for the different targets
so the patch tender is a canary build sort of thing, right?
that can be done
it's common enough to test canary but not on PRs
more like a scheduled job
once a day/week/month
rarely but it might happen so rather not have something that is broken for 6months or however long it takes till CLJS master is actually released
so maybe a monthly canary check?
then you'd get a mail saying that one broke
but you don't get spammed all the time
nah not needed. I watch CLJS master anyways and pretty much know what will break shadow-cljs anyways
its not that much stuff that will actually break shadow-cljs. last time it was a new binding that was added
anyways .. pretty much the only thing that makes sense for me right now is more tests
yeah I have no idea how to test the chrome and native targets
file watch is testable but requires some finesse
simple targets are nice to test size regressions
but a couple of representative apps, like the https://github.com/jacekschae/conduit or others, would be better to test correctness
because of the unpinned transitive ones?
as long as there's a lockfile, you should be getting the same js dep tree
I agree that js deps do break constantly, but doing js deps well it is the main draw for shadow-cljs, so it sounds worthwhile to test
that example has a lock file but I can't install it anymore because of one the deps doesn't like me being on the newer node
well that's a valid error, I guess that you updated the node version at some point
it still sucks, but is valid
thats a nonsense error though. there SHOULD be zero chance that this works in node v9 but not v10?
but that's part of the problem, right?
it was a surprise that the old example didn't run anymore because there was no test that verified it with a formal environment
things change too much. the storybook stuff works completely differently nowadays. it has basically nothing in common with the old code
hold on, I think there's a bit of conflating issues here...
the test from 2 years ago should run given a same-ish set of dependencies, including environment dependencies
it should run without source changes
tbh my experience trying to get most cljs things working is that almost all examples I find are outdated, and I mostly scavenge config items from one and another
it's still valuable to see how they worked, given that there's a reasonable guarantee that it still works (e.g. it's still tested and there;s an env that it works in)
once that exists, it's a matter of starting from that point and trying to make the new thing work
the only thing that is truly mandatory to keep up to date for shadow-cljs is its own config items
in theory yes. In practice if I can't clone an example and run it in my env it is probably pointless
to be fair that part isn't a node problem... clj suffers from that with java versions as well, doesn't it?
I remember I installed the latest java and it turned out a bunch of things just broke in weird ways until I went back to 8 or something
yes, the node dep system is a bit of a shitshow and things aren't very stable overall
is https://github.com/shadow-cljs/examples used for testing?
I found it really useful last weekend tbh, when I was trying to do devcards
it's really really hard to find examples for cljs stuff
personally I'd like even more JS parts since that's why I'm using shadow-cljs, but this is my consumer POV 😛
yeah, that was my view a couple years ago. that is why I wrote all the npm support after all. nowadays I'd much rather not use anything from that world 😛
that sounds a bit at odds with what I gather to be the point of shadow-cljs, but I imagine I'm too focused on my "use npm packages but with cljs" usecase to see the other large usecases
I never actually tried running either lein or the official clj tools more than... twice, I think
so I've never felt the difference between shadow-cljs and those
I'm on windows, and the official clj tools need powershell to run, and that's not my day to day shell
plus it doesn't have a lot of examples
lein seems great but what I really want is to keep access to the js ecosystem via npm so I don't see the point in using anything that doesn't give ergonomic access to that
give it a try 😉 hopefully makes it clear how much more important the config stuff is over JS intergration 😉
you can get npm sort of via https://clojurescript.org/guides/webpack
imho that approach is more of a POC than a real thing
maybe it makes sense if you use just a few npm packages... but once you start leaning heavily into js deps it just goes out door
managing a second build system and the interface point between the two is just more work for things that don't need to be more work
tbh baseline cljs just makes the existing js world be second class citizen, while shadow-cljs makes it a first class citizen
if you're a JS user (like me) why would you even consider trying cljs if the first step is to either let go of your existing ecosystem or maintain glue webpack builds? the overhead to start is very high like that
BUT ... that means people are reaching for npm all the time. even when there are "better" choices directly in CLJS or in the Closure Library
I get that impression, that the cljs world has much better options, but they are kinda hard to discover...
the incremental move from js to cljs is more manageable, you can start with your old stuff and move towards better stuff bit by bit, kinda like how TS got people to move over because you could just gradually opt into types
it's true, the conversion isn't too straightforward
personally I'm having loads of fun trying to make stuff work... I was trying to hook up reacts testing-library
to shadowcljs and devcards and it seems to be ok
coming from the js world I'm really stupified by how better the dev ux things are
one of the long term things I'd like to work on at some point is CLJS outputting plain ESM, no google closure stuff
have I mentioned https://www.pika.dev/registry?
it's mostly a ESM registry, so that helps with the discoverability of those packages
pure ESM won't become a reality until node adopts it
which happened... I think last week
package exports also seem to be happening
I think the transition is going to be really bad though
npm/package.json doesn't really have forward compat allowances
people are going to start publishing es2015 packages and everything will just break is weird ways
can see that already today when packages move to the "strict" CJS->ESM interop styles
so yeah, 5 years sounds like the reasonable timeframe
because of the esm output option?
webpack is a really bad tool for lib publishing overall imho
ahhh yeah that'll be good
that's also the reason webpack was so widespread though
because thing just worked... sorta, probably, sometimes
yeah I know .. it is tough. I'm not a huge fan of ESM either. the design seems silly in some parts
@thheller the reason I proposed to enable some CI is to make sure PRs have some minimum automatic checks, e.g. at least the clj compilation shall pass.
on top of that it'll be good to have some test coverage to make sure new contribution doesn't break existing stuff.
for travis it's as simple as a click in settings ui on http://travis.org
using circleci you have to tick a box that says PRs should be built... sec
open circleci, click settings cogwheel top right corner, follow image
it's not just about the overall coverage though
it also gives a lot more confidence to contributors
and it also provides a blueprint of what commands they should run locally that are guaranteed to be up to date
tbh the CI config is the only script that's guaranteed to work in most projects
So I'm working on a project with shadow-cljs, and I noticed that source-maps aren't working in firefox or chrome. Is that a known issue/do I need to specify any settings to fix that?
they are only enabled by default for compile/watch. release doesn't have them enabled by default.
don't need to set :source-map true
and :asset-path
is likely the issue. looks like that should be /js
?
Upgrading shadow-cljs from 68 to 72 is breaking our :npm-module
project in a strange way.
The shadow-cljs compilation works normally, but later in the process the files are called/consumed by webpack and it fails with:
/path/filename.js:37939
if(COMPILED){
^
ReferenceError: COMPILED is not defined
at Object../build/cljs/cljs.core.js (/path/filename.js:37939:1)
at __webpack_require__ (/path/webpack:/webpack/bootstrap:19:1)
...
I'm comparing the generated cljs.core.js
and the /path/filename.js
between the two versions, but sifting through 5.1mb of js will probably take a little while given the spurious (gensym) differences 😬/path/webpack:/build/cljs/cljs_env.js:181
throw new Error('Namespace "' + name + '" already declared.');
^
Error: Namespace "goog.math.Long" already declared.
at Object.module.exports../build/cljs/cljs_env.js.goog.module (/path/webpack:/build/cljs/cljs_env.js:181:1)
at /path/webpack:/goog/math/long.js:143:5
at Object.module.exports../build/cljs/cljs_env.js.goog.loadModule (/path/webpack:/build/cljs/cljs_env.js:474:1)
at Object../build/cljs/goog.math.long.js (/path/filename2.js:50051:6)