Fork me on GitHub
#shadow-cljs
<
2019-11-19
>
thheller00:11:27

what the heck?

thheller00:11:58

@tony.kay you are using deps.edn right?

thheller00:11:36

hmm let me test on macOS, maybe it does something linux/win don't

thheller00:11:03

hmm also working fine on macOS. @tony.kay is there anything special in your setup? can you check if .shadow-cljs/cli.check exists?

thheller00:11:07

the check was supposed to be more reliable, not less 😛

thheller00:11:04

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

thheller00:11:14

so that it can detect if the node process got killed

thheller00:11:49

(solving a problem from a while ago that there would be zombie JVM processes if node got killed or exited)

tony.kay01:11:07

I can check later..I’m cranking on something and just had to revert. Using straight deps.edn, and yarn for deps install

Sean Poulter04:11:53

👋 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.

tony.kay16:11:35

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

👍 4
thheller01:11:25

just published [email protected] ... hope that variant is actually more reliable ... unless you are still on java 1.8 I guess 😛

Sean Poulter04:11:12

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. 👍

Shuai Lin15:11:36

@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.

Shuai Lin15:11:52

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)

Filipe Silva11:11:53

@thheller WDYT of setting up github actions instead of circle and testing across linux/osx/windows?

Filipe Silva11:11:07

I could set that up for you if you're interested

thheller11:11:53

there are barely any tests to begin with so not all that useful currently

thheller11:11:02

it would be interesting to have some automated way that runs a "test" build for each new release

thheller11:11:11

dunno if that can be done with github actions

Filipe Silva11:11:28

I have something similar happening

thheller11:11:46

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

Filipe Silva11:11:06

in my case, releases are done automatically, and the release is tested if done

Filipe Silva11:11:25

but I think a workflow can also be set that is triggered on tags

Filipe Silva11:11:49

e.g. you make the release manually, then push the tag, then the workflow runs on the tag

Filipe Silva11:11:55

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

thheller11:11:28

but I guess that doesn't matter too much

Filipe Silva11:11:05

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

Filipe Silva11:11:19

so the patch tender is a canary build sort of thing, right?

Filipe Silva11:11:28

that can be done

thheller11:11:32

hmm now that I think about it forget about that

thheller11:11:45

sometimes changes in CLJS may require changes in shadow-cljs

Filipe Silva11:11:00

it's common enough to test canary but not on PRs

Filipe Silva11:11:04

more like a scheduled job

Filipe Silva11:11:12

once a day/week/month

thheller11:11:16

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

Filipe Silva11:11:45

so maybe a monthly canary check?

Filipe Silva11:11:55

then you'd get a mail saying that one broke

Filipe Silva11:11:00

but you don't get spammed all the time

thheller11:11:38

nah not needed. I watch CLJS master anyways and pretty much know what will break shadow-cljs anyways

thheller11:11:52

often before the commit even comes in via Jira

thheller12:11:12

its not that much stuff that will actually break shadow-cljs. last time it was a new binding that was added

thheller12:11:46

anyways .. pretty much the only thing that makes sense for me right now is more tests

thheller12:11:25

but I don't know what or how to test stuff like hot-reload, file watching etc

thheller12:11:50

or all the possible build targets .. eg. :chrome-extension or :react-native

thheller12:11:17

simple builds aren't worth testing most of the time either

Filipe Silva12:11:38

yeah I have no idea how to test the chrome and native targets

Filipe Silva12:11:46

file watch is testable but requires some finesse

Filipe Silva12:11:04

simple targets are nice to test size regressions

Filipe Silva12:11:50

but a couple of representative apps, like the https://github.com/jacekschae/conduit or others, would be better to test correctness

thheller12:11:19

yeah but as soon as you introduce JS deps I'm going to expect constant breakage

thheller12:11:30

and I'd rather not have to keep up with that mess 😛

Filipe Silva12:11:44

because of the unpinned transitive ones?

thheller12:11:48

because JS deps break constantly 😛

Filipe Silva12:11:20

as long as there's a lockfile, you should be getting the same js dep tree

Filipe Silva12:11:02

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

thheller12:11:05

in theory yes, in practice no. example from yesterday

thheller12:11:31

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

Filipe Silva12:11:01

well that's a valid error, I guess that you updated the node version at some point

Filipe Silva12:11:22

it still sucks, but is valid

thheller12:11:42

thats a nonsense error though. there SHOULD be zero chance that this works in node v9 but not v10?

thheller12:11:58

I'm betting this works with node v12

thheller12:11:06

its just a nonsense setting in that package 😛

thheller12:11:20

well anyways ... I don't want to deal with node stuff breaking

thheller12:11:32

I can't even keep up with that breaking for the few examples

Filipe Silva12:11:02

but that's part of the problem, right?

thheller12:11:26

the problem is node/npm not being very stable

thheller12:11:33

there is no way I'm going to make that more stable

Filipe Silva12:11:42

it was a surprise that the old example didn't run anymore because there was no test that verified it with a formal environment

thheller12:11:04

no it is impossible to keep the old examples running

thheller12:11:26

things change too much. the storybook stuff works completely differently nowadays. it has basically nothing in common with the old code

Filipe Silva12:11:53

hold on, I think there's a bit of conflating issues here...

Filipe Silva12:11:19

the test from 2 years ago should run given a same-ish set of dependencies, including environment dependencies

Filipe Silva12:11:26

it should run without source changes

thheller12:11:41

but it is pointless to keep that running

thheller12:11:59

nobody is gonna want to use a 2 year old version of storybook

thheller12:11:07

none of the current docs are going to apply

thheller12:11:32

so at best it is a "hey, this is how it worked 2 years ago"

Filipe Silva12:11:46

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

thheller12:11:49

"but nowadays things are different, don't look at this"

Filipe Silva12:11:53

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)

Filipe Silva12:11:11

once that exists, it's a matter of starting from that point and trying to make the new thing work

Filipe Silva12:11:40

the only thing that is truly mandatory to keep up to date for shadow-cljs is its own config items

thheller12:11:47

in theory yes. In practice if I can't clone an example and run it in my env it is probably pointless

Filipe Silva12:11:44

to be fair that part isn't a node problem... clj suffers from that with java versions as well, doesn't it?

Filipe Silva12:11:06

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

thheller12:11:54

yeah sure this isn't node only. but it is much more common in node.

Filipe Silva12:11:28

yes, the node dep system is a bit of a shitshow and things aren't very stable overall

thheller12:11:41

the move off jdk1.8 was a bit messy indeed

thheller12:11:29

no. I wanted to delete that repo for a while now

thheller12:11:56

good chance lots of them are not actually working anymore 😛

Filipe Silva12:11:56

I found it really useful last weekend tbh, when I was trying to do devcards

Filipe Silva12:11:38

it's really really hard to find examples for cljs stuff

thheller12:11:39

yeah. I want better examples too but want to cut down on the JS parts

thheller12:11:22

to be fair there are fairly "stable" npm packages too. it isn't all bad.

Filipe Silva12:11:44

personally I'd like even more JS parts since that's why I'm using shadow-cljs, but this is my consumer POV 😛

thheller12:11:37

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 😛

Filipe Silva12:11:57

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

thheller12:11:34

the point of shadow-cljs is CLJS compilation. supporting JS/npm is like 10% of that

thheller12:11:05

easier config, dedicated :target configs, etc is way more important (IMHO)

Filipe Silva12:11:36

I never actually tried running either lein or the official clj tools more than... twice, I think

Filipe Silva12:11:52

so I've never felt the difference between shadow-cljs and those

Filipe Silva12:11:25

I'm on windows, and the official clj tools need powershell to run, and that's not my day to day shell

Filipe Silva12:11:34

plus it doesn't have a lot of examples

Filipe Silva12:11:23

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

thheller12:11:29

give it a try 😉 hopefully makes it clear how much more important the config stuff is over JS intergration 😉

Filipe Silva12:11:46

imho that approach is more of a POC than a real thing

thheller12:11:21

lots of people do use it that way though

Filipe Silva12:11:37

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

Filipe Silva12:11:13

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

Filipe Silva12:11:00

tbh baseline cljs just makes the existing js world be second class citizen, while shadow-cljs makes it a first class citizen

thheller12:11:04

yes, I wanted to make that easier

Filipe Silva12:11:54

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

thheller12:11:56

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

thheller12:11:34

yes, this all needed to be more accessible for JS devs

Filipe Silva12:11:10

I get that impression, that the cljs world has much better options, but they are kinda hard to discover...

thheller12:11:11

but there is a downside to it ...

Filipe Silva12:11:14

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

thheller12:11:28

incremental IMHO isn't that easy since idiomatic CLJS looks nothing like JS

thheller12:11:45

but it should be possible to do regardless

Filipe Silva12:11:16

it's true, the conversion isn't too straightforward

Filipe Silva12:11:10

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

Filipe Silva12:11:38

coming from the js world I'm really stupified by how better the dev ux things are

thheller12:11:32

one of the long term things I'd like to work on at some point is CLJS outputting plain ESM, no google closure stuff

thheller12:11:39

that should make interop much much easier

thheller12:11:57

not sure that is actually practical though

thheller12:11:15

yeah I've seen that

Filipe Silva12:11:29

it's mostly a ESM registry, so that helps with the discoverability of those packages

Filipe Silva12:11:43

pure ESM won't become a reality until node adopts it

Filipe Silva12:11:48

which happened... I think last week

thheller12:11:52

yes a pure ESM world would be nice

thheller12:11:13

but there are lots of problem with ESM that also need to be solved first

thheller12:11:24

import maps, declared exports in package.json and so on

Filipe Silva12:11:55

package exports also seem to be happening

thheller12:11:23

> Experimental support for ECMAScript modules is enabled by default.

thheller12:11:27

still experimental though 😉

thheller12:11:54

yes that all looks good

thheller12:11:01

might actually work in 5 years or so 😉

Filipe Silva12:11:07

I think the transition is going to be really bad though

Filipe Silva12:11:21

npm/package.json doesn't really have forward compat allowances

thheller12:11:23

indeed. really bad indeed.

Filipe Silva12:11:49

people are going to start publishing es2015 packages and everything will just break is weird ways

thheller12:11:51

can see that already today when packages move to the "strict" CJS->ESM interop styles

Filipe Silva12:11:09

so yeah, 5 years sounds like the reasonable timeframe

thheller12:11:12

one of the reasons I want to get out of that world 😛

thheller12:11:35

once its done it'll be better but the transition is gonna suck

thheller12:11:55

hope that a final webpack v5 release will speed that along a bit

Filipe Silva12:11:23

because of the esm output option?

Filipe Silva12:11:59

webpack is a really bad tool for lib publishing overall imho

thheller13:11:38

no webpack v5 is moving to strict interop by default

thheller13:11:07

so import {foo, bar} from "x"; will break if x is a commonJS package

thheller13:11:22

only import X from "x"; and X.foo will be allowed

thheller13:11:53

so that should kind of force more packages actually publishing ESM code

thheller13:11:58

but we'll see about that 😛

thheller13:11:37

the problem is the "compatibilty" mode that babel/webpack allowed

Filipe Silva13:11:41

ahhh yeah that'll be good

thheller13:11:45

that can never work when actually following the spec

Filipe Silva13:11:18

that's also the reason webpack was so widespread though

Filipe Silva13:11:30

because thing just worked... sorta, probably, sometimes

thheller13:11:16

yeah I know .. it is tough. I'm not a huge fan of ESM either. the design seems silly in some parts

Shuai Lin13:11:26

@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.

Shuai Lin13:11:28

on top of that it'll be good to have some test coverage to make sure new contribution doesn't break existing stuff.

thheller13:11:42

yeah how do I get that setup for PRs?

Shuai Lin13:11:08

for travis it's as simple as a click in settings ui on http://travis.org

Filipe Silva13:11:17

using circleci you have to tick a box that says PRs should be built... sec

Filipe Silva13:11:00

open circleci, click settings cogwheel top right corner, follow image

thheller13:11:14

ok thanks. should be enabled now

thheller13:11:27

but yeah getting tests to cover that all is kinda hard 😛

Filipe Silva13:11:05

it's not just about the overall coverage though

Filipe Silva13:11:12

it also gives a lot more confidence to contributors

Filipe Silva13:11:39

and it also provides a blueprint of what commands they should run locally that are guaranteed to be up to date

Filipe Silva13:11:00

tbh the CI config is the only script that's guaranteed to work in most projects

donyorm21:11:56

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?

thheller21:11:40

they are only enabled by default for compile/watch. release doesn't have them enabled by default.

thheller21:11:08

but they should be working fine without extra settings in compile/watch

donyorm21:11:21

Hmmmm, I'm using compile/watch

donyorm21:11:35

Here's my shadow-cljs.edn file if you need it

thheller21:11:24

don't need to set :source-map true and :asset-path is likely the issue. looks like that should be /js?

donyorm21:11:38

Ok, let me check

thheller21:11:57

you can also remove the clojurescript dependency, shadow-cljs adds that by default

aisamu22:11:06

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 😬

thheller22:11:04

can you check a bit more of the code?

thheller22:11:15

would like to know which part of the code that actually is

thheller22:11:21

just search for COMPILED

thheller22:11:44

oh it is actually in cljs.core itself

thheller22:11:57

@aisamu try 2.8.73

👍 4
aisamu22:11:00

The error changed, but I'd call that progress 😛

aisamu22:11:55

/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)

aisamu22:11:43

Did it twice after a full nuke to confirm 😕

thheller22:11:35

guess its best to stick with the older version for now

👌 4
thheller22:11:44

need to dig into :npm-module a bit more

aisamu22:11:17

Thanks! Please don't hesitate to reach out if you need more info/some testing