3 ms·
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 pr
by austincheney 6y ago
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 6y ago> 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 6y agoFYI PowerShell is pretty cross-platform these days. But I see having it all written in JS is still simpler.
- TechBro8615 6y agoI 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 6y agoI'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 6y agoYes, 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 6y agoBut almost none of the instructions provided in the article are JavaScript. They are shell commands.