This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-27
Channels
- # announcements (2)
- # aws (31)
- # babashka (81)
- # beginners (82)
- # calva (38)
- # clj-kondo (41)
- # cljdoc (4)
- # cljs-dev (6)
- # clojure (101)
- # clojure-belgium (1)
- # clojure-europe (30)
- # clojure-germany (1)
- # clojure-italy (7)
- # clojure-nl (4)
- # clojure-norway (1)
- # clojure-spec (1)
- # clojure-uk (19)
- # clojurescript (16)
- # clojutre (1)
- # community-development (26)
- # core-logic (2)
- # data-science (26)
- # datomic (71)
- # events (3)
- # fulcro (55)
- # graalvm (2)
- # graphql (3)
- # joker (2)
- # kaocha (19)
- # luminus (2)
- # malli (6)
- # meander (3)
- # off-topic (6)
- # pathom (34)
- # random (1)
- # re-frame (2)
- # robots (1)
- # shadow-cljs (37)
- # sql (30)
- # tools-deps (21)
- # xtdb (4)
- # yada (25)
ran into an issue where an npm package I was using had it’s own nested node_modules folder, and the require
call in it’s code was importing the package in the root of my project’s node_modules
directory, which came from another libraries dependencies. I don’t think this is wrong but does anyone know what’s happening in JS land that some dependencies get flattened out
the work around is to reroute the dependency, just looking for clarification
"history" {:target :npm :require "@elastic/search-ui/node_modules/history"}
I think I understand where you’re coming from by not supporting searching in a nested node_module directory, but new to clojurescript folks can get tripped up big time when encountering this. It’s not obvious what the issue is when you’re debugging “Why is it saying this function doesn’t exist on the package?”
I’m going to try and solve this on the yarn side of the house, I get the logic behind sticking to flat dependencies. My coworker who’s new to Clojurescript was/is very frustrated by this 😞 And I do think it’s kind of a rare occurrence, just unfortunate to happen to him, and I didn’t know what was going on for a while. Looking through transpiled javascript dependencies is not fun.
Have you dealt with the util
package before? https://www.npmjs.com/package/util
Should all users of shadow-cljs just run npm i util
if some other package assumes that util
is available?
I'm guessing that you should install shadow-cljs in the project so the polyfills it depends on are also installed
You said about a year ago that it should be in the regular dependencies
.
This is not fine on Heroku, where it builds the production build, thus not installing anything in devDependencies
.
I said you can't put it in there if you install dependencies with the production profile
IIRC you said that it makes no sense to use dev
because anything unneeded just won't be used at all, thus there's no point in this explicit separation. But never mind.
The thing is, I didn't really need shadow-cljs as an NPM package in order to build the release version.
And of course it broke when I upgraded tinymce-react
.
I'd blame tinymce-react
for not specifying util
as one of the dependencies. Hate this implicit stuff.
God dammit.
The required JS dependency "inherits" is not available, it was required by "node_modules/util/util.js".
Why does everything have to be implicit with all this stuff?webpack5 is gonna deprecate those implicit node packages so people will hopefully stop doing that
but who knows when that will be released. they've been talking about it for a while now.
No worries, there will always be some other thing that people start doing because it's "clever". :(
I suspect most people do it because webpack just works that way. If it warned then people would likely pay more attention
So, I did move shadow-cljs to the regular dependencies
. I even upgraded NPM and removed node_modules
. And would you look at that. And of course it doesn't work.
At this point, I hate NPM with so much passion, it might be just enough to write a sensible alternative to it. Unless it exists?
need to delete that too. otherwise you'll get exactly the same structure you had before deleting everything
@p-himik you probably considered this already but an alternative way to structure your deployment is to keep a separate bare branch (like what gh-pages
is for GitHub pages) and version only your production artifacts in there, and this is what you push up to Heroku, not your dev branch. Another way to do it is have a separate shadow-cljs declaration for generating your prod build artifact which builds to a different location than the dev version, and have the build artifact versioned also.
Using these methods you don't need to even run npm install
on the remote as everything is bundled into the artifact.
Honestly, I don't like approaches where I need to version artifacts. It may make things easier for Heroku specifically, and specifically when I'm the only developer. But before switching to it, I would rather switch to something else entirely because I'm gradually getting more weary of Heroku. Anyway, thanks for the idea!
understood, totally get that as I am also weary of Heroku.