This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-17
Channels
- # announcements (8)
- # atom-editor (8)
- # aws (1)
- # babashka (96)
- # beginners (128)
- # calva (7)
- # cider (12)
- # cljsrn (1)
- # clojure (75)
- # clojure-europe (28)
- # clojure-hamburg (2)
- # clojure-italy (7)
- # clojure-nl (7)
- # clojure-norway (3)
- # clojure-uk (13)
- # clojurescript (26)
- # conjure (2)
- # cursive (18)
- # data-science (7)
- # datalog (21)
- # datomic (9)
- # duct (15)
- # expound (29)
- # figwheel-main (14)
- # fulcro (59)
- # helix (4)
- # jobs (2)
- # kaocha (19)
- # leiningen (15)
- # luminus (4)
- # malli (57)
- # meander (2)
- # off-topic (2)
- # pathom (12)
- # pedestal (8)
- # re-frame (53)
- # reitit (9)
- # remote-jobs (1)
- # shadow-cljs (64)
- # spacemacs (1)
- # specter (2)
- # tools-deps (12)
- # tree-sitter (2)
- # vim (11)
- # xtdb (17)
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 https://www.npmjs.com/package/source-map-explorer in shadow-cljs bundles?
I built https://github.com/stevebuik/stu 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
you can use source-map-explorer yes. or just the regular build reports https://shadow-cljs.github.io/docs/UsersGuide.html#_build_report
ATM we can't use SME https://github.com/danvk/source-map-explorer/issues/190
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
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 https://github.com/thheller/shadow-cljs/blob/f82cffe1b8904e412ed8402b9f90b9d104599601/src/main/shadow/build/npm.clj#L709
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?
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.
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: https://github.com/thheller/shadow-cljs/commit/36e63a7801a2bafe0140fe9e49dbada9233335f8#diff-6f236ccd9b9e2a1e666f13927b75d522L3-R3 but shadow.cljs.devtools.server/reload!
tries to call vreset!
on it here: https://github.com/thheller/shadow-cljs/blob/6252e3b0843b21cfda49fe77bd0e51ad7b32782f/src/main/shadow/cljs/devtools/server.clj#L526. 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.
@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.
no clue. nobody mentioned this before. only when the filename was actually incorrect.
I was running into a problem similar to https://github.com/thheller/shadow-cljs/issues/733 so I tried to create the missing repro
I'm not sure if the problem I can repro is exactly the same
but I opened https://github.com/thheller/shadow-cljs/issues/777 with a repro
it looks like in some cases $jscomp
isn't there
(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}
thanks for taking the time
the weird part about this one is that the exact same code runs fine in :browser-test
but not in :karma
I can confirm that adding :compiler-options {:output-feature-set :es8}
to the karma target sorts it out
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