Fork me on GitHub

Quick question about cljs-shadow in a project from luminus. To work with CIDER, we have to move the cljs-shadow part out of the project file, correct?


Is it still using that plugin? If so, it’s advisable to move it out. It’s an extra layer of tooling for no real benefit. It makes diagnosing problems harder.


I’m back to my project after a couple of months delay, and trying to get CIDER to connect to both clj and cljs. I have a project where this is working, but when starting from scratch with a more recent luminus template, it’s failing. I feel like I solved this before, but failed to write it down.


Ok, it’s working again. Now I have to figure out why….


Before I try to extract the shadow config from the project file again


Can I use any tool like in shadow-cljs bundles?


I built to do exactly this. I tried it recently and it still works with latest shadow


it’s got a couple of bugs, the most important being that it needs 2 releases for the bar chart to appear


I can fix them if you want to use it regularly


or I can help you fix them


you can use source-map-explorer yes. or just the regular build reports


Report is awesome!


Q: when I update from v2.8.101 to v2.10.21 I am blocked by a compilation error from prosemirror. I am not an expert at npm so I could use some help. I’ll start a thread with the details….


The required JS dependency "!!../../css-loader/index.js!./prosemirror.css" is not available, it was required by "node_modules/@aeaton/react-prosemirror/dist/index.js". Dependency Trace: nextdoc/devcards.cljs nextdoc/text_editor.cljs nextdoc/common/text_editor/editor.cljs node_modules/@aeaton/react-prosemirror/dist/index.js


I’ve checked and the prosemirror.css is present in the node_modules dir


I’m pretty sure it’s this require that is breaking…


for now, I’ll workaround by staying on the older version of shadow. I guess that shadow or cljs is doing more checking so it’s desirable to upgrade?


:js-options {:ignore-asset-requires true} will ignore the css require which it previously did by default or warnings


thanks. I tried this but it made no difference. is it possible that promemirrors use of css-loader is not handled by the ignore? I ran the build using the Cursive debugger with a breakpoint here


the .css import never hits that line. I used a conditional breakpoint to verify other file types and .js files do go through there. Would the react-prosemirror import go through another mechanism?


@thheller I can stay on the older version for now so not blocked.


honestly I'd just recommend staying away from packages that have some weird hardcoded webpack references. who knows what other issues it will have. can't really support all of that weirdness.


ok. it’s a shame because react-prosemirror removes a lot of custom code/complexity. I’ll look for an alternative. worst case, I’ll have to stay with v2.8. not ideal but it’ll work


I might try patching that wrapper and removing the css-loader. that will work too. I’d rather have the latest shadow if possible


I'd just open an issue on the react-prosemirror package. it is often just an oversight if things like that remain in code.


that’s a good idea. thx


there are other wrappers out there too. I can try them instead


Hmm.. it seems to me that shadow.cljs.devtools.server/reload! is broken. shadow.cljs.devtools.server.runtime/instance-ref got changed into an atom here: but shadow.cljs.devtools.server/reload! tries to call vreset! on it here: I guess reload! should call reset! instead.


@flowthing I forgot that fn even exists. why do you want to call it?


I was updating dependencies in one of my work projects and this turned up. I’m not the original author, so I’m not sure why the call to reload! is there. The callsite is in a user/reset type function.


It probably isn’t necessary to call reload! at all there, though… need to dive into it a bit.


@flowthing you can just call (server/stop!) (server/start!) instead I guess


Hi, I got a really strange bug.. “Invalid Filename, got app/something/events.cljs but expected app/something/events.cljs (or .cljc)” .. did you get similar error message..? I played with that around few hours.. I need to delete the file and recreate. So strange.. on OSX.


(Im not sure that is shadowcljs related, ..I don’t know)


@thheller Yep. In this case, I don’t think I even need to do that, though.


@sb make sure you have the actually correct filename. this should only appear if the filename has a typo or something? easy to miss typos if the listed names look mostly similar.


I needed delete the file and recreate with same content. Nothing changed. Really strange.. Yes I checked everything x20.. because I thought here is typo but not.. I don’t know what was that.


did if have a - in the name?


Nothing extra, that was reframe events file.


(Just I thought that is maybe happened with others too.)


no clue. nobody mentioned this before. only when the filename was actually incorrect.

Filipe Silva15:08:11

I was running into a problem similar to so I tried to create the missing repro

Filipe Silva15:08:29

I'm not sure if the problem I can repro is exactly the same

Filipe Silva15:08:15

it looks like in some cases $jscomp isn't there

Filipe Silva15:08:41

(as in, at all, the reference was never declared)


with all of these the easy fix is just preventing the polyfilling completely if you know the engine supports it. just set :compiler-options {:output-feature-set :es8}


I'll take a look when I have some time

Filipe Silva15:08:40

thanks for taking the time

Filipe Silva15:08:07

the weird part about this one is that the exact same code runs fine in :browser-test but not in :karma


might just be that karma doesn't declare the global properly. not sure.

👍 3

handling of all of this is kinda hacky but I don't know how to clean it up properly

Filipe Silva15:08:52

I can confirm that adding :compiler-options {:output-feature-set :es8} to the karma target sorts it out

Filipe Silva15:08:04

will add that to the issue


Re that $jscomp in karma error we have just started using :output-feature-set :es6 about a week ago to workaround this issue and no problems so far. I think es5 is pretty much obsolete anyway as the only browsers that would matter for are Internet Explorer series (not MS Edge). So it should probably be asked, does anyone actually need es5 level polyfills by default ? @thheller @filipematossilva


IE11 is still quite common as a requirement

👍 3

but I could probably bump the :karma default


honestly I'd just rather fix $jscomp not working properly. will figure out why its missing when I have time

👍 3