3 ms·

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" fiel

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?

zemo 2y ago
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 https://just.systems/man/en/shebang-recipes.html
- soulofmischief 2y ago
  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!
lolinder 2y ago
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.
- soulofmischief 2y ago
  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 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.
  - soulofmischief 2y ago
    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.
gurgeous 2y ago
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.
Izkata 2y ago
"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.
- soulofmischief 2y ago
  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.

zemo 2y ago

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 https://just.systems/man/en/shebang-recipes.html

soulofmischief 2y ago
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!

lolinder 2y ago

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.

soulofmischief 2y ago
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 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.
- soulofmischief 2y ago
  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.

gurgeous 2y ago

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.

Izkata 2y ago

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

soulofmischief 2y ago
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.