npx anmol: a business card that runs from the command line

The whole interaction is one command

npx_card exists so that a person can be introduced by running a command. The README puts it plainly, that this is the author's npx card in a unique style, to connect with them directly via console or terminal, and the instruction is to hit a single command.

npx anmol

That is the entire user interface. There is no install step, no configuration file and no account, because npx fetches the package and runs it. The output is a card, and the README says the final output might look something like the demo recording included in the repository as demo.gif. The nature of the thing is worth being clear about, because it determines how you should judge it. This is a personal presence project rather than a tool, a way of making a profile link reachable from a shell, and the measures of success are different from those of a library. The author says as much in the README, noting that they spent a non-trivial amount of effort building and designing this iteration and are proud of it, asking only for a star on the project and that the effort is not claimed as someone else's. The name of the package is anmol, the version is 5.1.0, and the package is published on npm under that name rather than under the repository name, which is a deliberate choice so that the command a user types is short.

Links that are clickable where the terminal allows it

The one technical detail that distinguishes this card from a block of ASCII art is how the links behave. The Twitter, GitHub, LinkedIn and website links on the card are clickable in terminals that support hyperlinks, and the README names them, iTerm2, Windows Terminal, VS Code, GNOME Terminal and Hyper. On other terminals they are printed as plain URLs, so a command or control click still works. That fallback is the part that makes the approach practical, since it degrades to something usable rather than to nothing. The mechanism is the terminal-link package, which emits the escape sequence that a supporting terminal turns into a clickable region, and the detection of whether the sequence will be honoured is what allows the plain URL to be printed instead. The result is a card that behaves like a link on a modern terminal and like a piece of text on an old one, which is the right trade for something whose whole job is to be pointed at. The rest of the output is styling, which is where the other dependencies come in, and the README calls the result a unique style rather than describing it as functional output.

The dependency list is a map of the card's parts

The package manifest is small and the dependencies describe exactly what the card does. boxen is the frame around the content, the box drawing that gives the output its card shape. chalk handles the colouring of the text. cli-spinners and ora are the spinner libraries, and ora in particular provides the animated spinner that runs while the card is being assembled, since the script opens a URL and gathers content before it can print anything. clear is the package that wipes the terminal, which explains why the card appears as the only thing on screen. inquirer is the prompt library, which is what lets the card ask a question rather than only print. open is used to launch a URL in the system browser when the user chooses a link. request is the HTTP client used to fetch whatever the card displays. terminal-link is the hyperlink support described above. The interesting detail is that this is a dependency set with a certain age to it. The versions are chalk at 4.1.0, boxen at 4.2.0, ora at 5.1.0, inquirer at 7.3.2, open at 7.0.4, request at 2.88.2 and terminal-link at 2.1.1, and several of those are major versions behind what is current, which for a package whose entire payload is a card is a reasonable trade but one that will eventually need attention. The manifest also wires the package for execution, with card.js as the main entry and a bin mapping of anmol to the ./card.js path, so the npx anmol command works because of that mapping rather than because of a shebang convention.

Releases are cut from a workflow, not from a laptop

The publishing section is the most operational part of the README and it describes a release process that is fully automated. Releases are published to npm straight from GitHub Actions, with no local npm publish needed. The one-time setup is to create an npm Automation access token and add it to the repository as a secret named NPM_TOKEN, in the repository settings under secrets and variables for actions. After that, the release is triggered from the Actions interface, choosing the Publish to npm workflow and running it with a version bump of patch, minor or major. The workflow then bumps the version, publishes the package to npm with provenance, and pushes the release commit and a vX.Y.Z tag back to the branch. Two details in that sentence matter. Publishing with provenance means the npm registry records the link between the published artefact and the workflow that produced it, which is the supply chain attestation that npm supports. And pushing the tag back to the branch, rather than leaving the tag only on the registry side, keeps the repository and the registry in step, which means a checkout of the repository tells you exactly what was published. The package manifest still carries a manual pub script that runs a major version bump and then npm publish, so the manual path exists as a fallback even though the workflow is the intended route.

The repository is a template as much as a card

The steps to create your own section is the part that turns this from a personal project into a pattern, and it credits the approach to another person, saying that the article was written by a friend and that the same reference was used to deploy the package. The link is to a piece titled Write a Simple npx Business Card, and the fact that it is credited in the README is a good sign about how the author treats other people's work. The implication for a reader is that this repository is a working reference implementation with a small number of files to change, which makes it far more useful to others than a purely personal project would be. The top level of the repository reflects that simplicity, with a .github/ directory holding the workflows, a .gitignore, the README, the card.js file that does the work, the demo.gif recording and a package-lock.json alongside the package.json. There is no source directory, no test suite and no build step, since the package runs directly from card.js and the test script is defined as running that file.

  "scripts": {
    "test": "node card.js",
    "pub": "npm version major && npm publish"
  },

The card's own content lives in that script, which is why forking the repository and editing a few lines is the whole procedure for making your own.

Where npx_card is the wrong choice

The first limit is that this is a display artefact rather than a data format, and the distinction matters for anyone hoping to build on it. There is no structured output, no machine readable profile and no flag that changes the destination, so the card is something a person runs for a person to see, and it cannot be part of a pipeline that collects contact details. The second is the supply chain surface, which is specific to the npx model rather than to this project. Running npx anmol downloads and executes code from the npm registry on a user's machine, which is the same trust model as any npm install but with a much shorter time to change, since the published version is whatever is on the registry today. The provenance support in the publishing workflow is a genuine mitigation and it is good that it is there, but it attests to the build rather than to the intentions of the code. The third is the age of the dependency set, and several of those pinned majors are far enough behind that a current Node environment is where compatibility questions will appear first. The fourth is the licence, and there is a discrepancy worth flagging before anyone builds on it. The repository listing records the licence as unknown, while the package manifest declares ISC, and an ISC licence is permissive but it is also short and specific about copyright holders, so a fork needs the copyright line to be correct. The fifth is the scope of the whole idea, since a card with a fixed set of links is a nice thing and the generalisation of it, a profile that pulls from several sources, needs the request and inquirer parts to be doing real work rather than decorative work, which is a project of its own.

Editorial conclusion

Adopt npx_card if you want a personal card that anyone can run with a single npx invocation, and you are willing to keep the card content in a script. Skip it if you need something you can embed in a resume pipeline, since this is a display artefact rather than a structured profile. Verify first that your terminal supports hyperlinks, that the package name you want is free on npm, and that the dependency set still installs cleanly on your Node version, since several of the pinned packages are several years old.

Frequently asked questions

Official sources

1. anmol098/npx_card on GitHub
2. Issues
3. README