Hacker News Reader

Comment by soulofmischief | Hacker News Reader

Can anyone with experience with just and tools like npm/yarn explain if there are any benefits to use just instead of codifying commands into the "scripts" field of the package.json? Commands can also be enumerated. How often would I benefit from just's other features?

View on HN

We don't use Just, but we have a Makefile that doesn't take advantage of any of Make's dependency features just to easily be able to run several commands in sequence.

JSON is just a really bad format for script configuration—you either have to string commands together on one big line with && or you have to pair package.json with some other strategy for organizing commands. That may end up being a `scripts` directory with a file per script, it could be that you use a framework that bakes all the complexity into shorter wrapper commands (a la vite), or you could use something like Just to sequence them.

It's not perfect but it gets the job done. Sometimes it's ugly but in the end it forces me to break commands down into subcommands, which can increase clarity.

But sometimes you do have to write a collection of script files for complex multi-line scripts. I assumed I would still do that with just? Is the idea for these to all live in a single just file? I like having larger programs separated as individual files. All good points, though. I like make too, but it can definitely be needlessly verbose. My main thing would be not wanting to need users to have another binary installed locally. Can just live in my repository?

Edit: Nevermind! https://just.systems/man/en/nodejs-installation.html

> `just-install` will install a local, platform-specific binary as part of the npm install command. This removes the need for every developer to install just independently using one of the processes mentioned above.

After digging into it more, it seems `just` requires `sh` to function, adding friction for Windows developers. I don't develop on Windows but that friction does reduce portability.

There's ambiguity in which package to use on Node. Both `just-install` and `rust-just` are recommended in the docs, with no disambiguation. `just-install` is maintained by another party and adds an attack surface I'm not sure I'm comfortable with given my current needs. The other recommended package, `rust-just` is also maintained by another party, has bad SEO and recommends being installed as a global dependency.

All of this just adds too much friction if one is already using a package.json. My monorepos frequently contain codebases in multiple languages and so far a package.json and workspaces workflow has met my needs.

I appreciate everyone for answering my questions and giving advice.

Actually, it was package.json scripts that pushed me toward just! I wanted that stuff in non-node projects (python/ruby/~), I wanted more complicated scripts, I wanted more logging output, I wanted comments... For whatever reason every project seems to have 10-20 little commands (often interdependent) and just makes that a breeze.

"yarn/npm install" has an artifact in the project directory, so here's one point for "make" instead of "just":

  start: node_modules
      yarn run start

  test: node_modules
      yarn run test

  node_modules: package.json yarn.lock
      yarn install
      touch $@

You can clone the repo and "make test", and it'll include "yarn install" automatically - then on subsequent "make test", it'll skip it because "node_modules" is already up-to-date. And then include it again later if someone updated the packages. The "touch" is so the last-modified timestamp on "node_modules" is updated even if "yarn install" doesn't add/remove anything, so make knows it succeeded.

"yarn install" is usually pretty fast when it has nothing to do, so I can see why people may not bother and just have it run every time, but patterns like this can be used for quite a bit. This way heavier commands don't need to be run repeatedly and devs don't need to know all the individual commands to run in sequence.

The touch trick is nice. There's definitely merit to such an approach, since it provides a simple cross-platform way to check if node_modules exists.

Though things begin to get more complicated if say, the project use plug-n-play resolution. `yarn` handles both cases.

Another benefit of `"test": "yarn && <test command>"` is that you also make sure the project is in a buildable state when testing.

package.json is specific to node projects, just can be used for anything. Why learn the quirks of something you can only use with a single programming language? I'm also a fan of the shebang recipes: https://just.systems/man/en/shebang-recipes.html

I place package.json files into non-node projects all the time just for some organizational benefits like workspaces and scripts. As a web-first engineer this doesn't particularly bother me. I'll check out shebang recipes, thanks!

Reply on news.ycombinator.com