Fork me on GitHub

I'm getting the following error when pulling in a new dependency, @fullcalendar/interaction:

Failed to inspect file

it was required from

Errors encountered while trying to parse file
  {:line 4, :column 1, :message "primary expression expected"}
So that common/main.js file is a transitive dependency and is trying to pull in CSS with import './main.css'. I read up on "JavaScript Dialects" and it looks like I would need to use a Babel plugin or somesuch to transform the CSS-in-JS, and then use Shadow to compile the transformed files. But does that basically mean I can't get this to work for a transitive dependency like common/main.js without forking my dependency, to tell it where to find the transformed files?


Is it best to run shadow-cljs commands so it executes the version local to the app repo? I just realize my globally installed shadow-cljs was ancient compared to the one in package.json in my repos. And I had been running watch and release with the global one. Haven’t had any issues, but I’m wondering if it would be better to just remove the global one and always do npx shadow-cljs or yarn shadow-cljs?


It's probably a good idea if it's a collaborative project, that way everyone is using the same version of shadow-cljs. It's a much bigger deal in JS Land, where APIs change every 20 minutes or so 😉


@ctamayo libraries like that pretty much expect to be bundled by webpack so you won't have much luck bundling with anything else. I'd recommend looking for a different lib.


I found this issue, looks like the author is making an earnest effort to support other build tools. The solution is a bit hacky but I'm wondering if shadow-cljs looks at the main module declared in package.json, rather than module? If so I think his proposed solution would apply to my case as well.


shadow-cljs looks at main by default

thheller15:07:32[email protected]/package.json also has no module at all so it doesn't seem to apply to that package


FWIW you can set :js-options {:ignore-asset-requires true} in your build config


that will make it compile but you will be missing the CSS


that's more what I was looking for, rock on!


@rberger shadow-cljs will automatically use the version installed in the project, even if using the global shadow-cljs install. you should always have a version installed in your project. the global install is optional though.


Cool, that is what I hoped (the local one would be used) but wanted to make sure. Glad to hear I don’t have to delete the global on to ensure that the local one in package.json is used.


well there might be a problem if you use a really old global install


it needs to be somewhat close in versions


otherwise the global install might not pick up features from the newer local one

Alex Porter14:07:27

We're following for code splitting but running into issues with deploying new versions of our app and the loading of a new view's js loads the wrong version. Any recommendations?


@thheller Thank you so much for shadow-cljs! I was able to make a quick change to a project that I haven’t touched in 6 months, confirm it works in a REPL, push out a change to Heroku, and have it running in production in about 30 minutes. Usually, it would be hours trying to get builds running again, and I’d be randomly changing versions of everything (cljs, clojure, random libraries), doing “lein clean”, heck, why not upgrade IntelliJ/Cursive, too, because nothing else seems to be fixing my build/run issues, etc. Days afterwards, encouraged by how easy everything is, I’ve made a nearly ten other changes — it makes front-end programming so incredibly fun, as opposed to full of dread and regret. 🙂

👍 12
☝️ 12

(Something really strange: it has been so long since I’ve done a build, the npm executable wasn’t even in my path anymore…. Huh! Whatever! 🙂

😂 9