Fork me on GitHub
#shadow-cljs
<
2020-03-27
>
haywood03:03:51

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

haywood03:03:58

the work around is to reroute the dependency, just looking for clarification

"history" {:target :npm :require "@elastic/search-ui/node_modules/history"}

haywood04:03:06

found some prior art

haywood04:03:43

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?”

haywood04:03:30

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.

p-himik21:03:45

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?

thheller21:03:50

I'm guessing that you should install shadow-cljs in the project so the polyfills it depends on are also installed

thheller21:03:56

which I believe includes util

p-himik21:03:15

Ah, right... Yeah, I still have shadow-cljs installed in devDependencies. picard-facepalm

thheller21:03:34

thats fine? and where it should be?

p-himik21:03:16

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.

thheller21:03:28

no I never said that

thheller21:03:46

I said you can't put it in there if you install dependencies with the production profile

thheller21:03:10

so don't install production dependencies if you intend to do "development"

thheller21:03:10

if your setup requires putting in into the dependencies then do it

thheller21:03:19

any regular setup is fine with devDependencies

p-himik21:03:23

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.

p-himik21:03:02

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?

thheller21:03:31

webpack5 is gonna deprecate those implicit node packages so people will hopefully stop doing that

thheller21:03:55

but who knows when that will be released. they've been talking about it for a while now.

p-himik21:03:30

No worries, there will always be some other thing that people start doing because it's "clever". :(

thheller21:03:23

I suspect most people do it because webpack just works that way. If it warned then people would likely pay more attention

p-himik21:03:03

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.

p-himik21:03:36

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?

thheller21:03:57

hmm? it should only install those nested if they already exist in the top lvl?

p-himik21:03:06

Nope, they don't exist.

thheller21:03:15

did you keep your lockfile?

thheller21:03:51

need to delete that too. otherwise you'll get exactly the same structure you had before deleting everything

p-himik21:03:00

That was it! Thanks.

p-himik21:03:27

I was under the impression that the lock file is only useful with npm ci.

Chris McCormick23:03:52

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

Chris McCormick23:03:29

Using these methods you don't need to even run npm install on the remote as everything is bundled into the artifact.

p-himik09:03:31

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!

Chris McCormick11:03:52

understood, totally get that as I am also weary of Heroku.