[austincheney]

That is a lot of boilerplate and reliance on external tooling that could probably be a single bash or PowerShell script.

My preferred approach is to let thy primary modules be thy commands. That way everything is tidy, documented, and clear for your users. Example:

    // module commandName is a module to parse a command, exclusion list, and options apart from other arguments of process.argv
    import commandName from "./lib/terminal/utilities/commandName.js";
    // module commandList is the list of modules that serve as commands for your application
    import commandList from "./lib/terminal/utilities/commandList.js";
    // module command_documentation provides documentation to the terminal about your commands and each of their options
    import commands_documentation from "./lib/terminal/utilities/commands_documentation.js";
    // module vars is a generic configuration store available across the application
    import vars from "./lib/terminal/utilities/vars.js";
    
    (function terminal_init_execute():void {
        // command documentation
        vars.commands = commands_documentation;

        // supported command name
        vars.command = commandName() as commands;

        commandList[vars.command]();
    }());

What it looks like on the terminal:

    node myApplication myCommand

[TechBro8615]

> probably be a single bash or PowerShell script

The fact that it could be either bash or PowerShell is a primary reason why this tooling is there. Bash scripts work great (I use them) if everyone coding on the project shares an operating system. Not so much once you cross that boundary.

To give a sense of the lengths the JS community goes to address these compatibility issues, consider that Yarn 2 actually implements its own shell for running `package.json` scripts in a cross-platform way.

[tompazourek]

FYI PowerShell is pretty cross-platform these days.

But I see having it all written in JS is still simpler.

[TechBro8615]

I don't know about simpler :)

My preference is to eliminate the OS discrepancy by making Docker images the building block of the stack in dev environments, CI pipelines, and production deployments. This means you pay a constant and predictable amount of operational complexity, but eliminate the entire class of constraints caused by cross-platform variability. Seems like a good deal, trading a variable cost for a constant one.

Then you can use Bash! Or fish, or some hipster shell you found on lobste.rs. Just install it in the Docker image.

[tompazourek]

I've read about NixOS here on HN which aims to do something similar.

Does your approach with using docker heavily have some disadvantages you experienced? Just curious, it sounds interesting...

[TechBro8615]

Yes, lots. You need to pay operational complexity early and often. A lot of tools don't work out of the box due to volume sharing, permission issues, etc. You need to figure out dev vs. prod images, how to do incremental builds locally (e.g. you switch branches) and in CI (new push). Lots of issues like this.

Overall it's worth it in the end if you're making a long term investment, IMO. It forces you to build modular infrastructure from the beginning, so there are few surprises when pushing to prod.

[austincheney]

But almost none of the instructions provided in the article are JavaScript. They are shell commands.