DEV Community: Wiktor Małyska

node --test only learned about globs in Node 21

Wiktor Małyska — Tue, 01 Sep 2026 13:00:00 +0000

My package declares support for Node 18 and up. Its own test suite could not run on two of the three versions I claimed to support. Everything passed on my machine.

The script

{
  "scripts": {
    "test": "node --test \"test/**/*.test.mjs\""
  },
  "engines": { "node": ">=18" }
}

That looks fine. It is quoted, so the shell does not expand it, which is what you want when a tool does its own glob handling. On my Node 22 it ran 35 tests and went green.

What CI said

The workflow was nine jobs: Ubuntu, Windows and macOS across Node 18, 20 and 22.

Could not find '/home/runner/work/pkg/pkg/test/**/*.test.mjs'
> node --test "test/**/*.test.mjs"
Error: Process completed with exit code 1

macOS 22 green. Ubuntu 18 red. Windows 20 red. The pattern was not the operating system, it was the Node version.

Why

Glob expansion in the Node test runner arrived in Node 21. Before that, a path argument is treated as a literal path. So on 18 and 20 the runner looks for a directory literally named **, does not find it, and dies before a single test executes.

It never even reached the tests. The suite was not failing; it was not running.

The fix

{
  "scripts": {
    "test": "node --test"
  }
}

With no path argument, the runner discovers test files itself using its default patterns, which include **/*.test.mjs and anything under a test/ directory. That behaviour has been there since Node 18, and it does not depend on the shell, so it works the same on Windows.

Same 35 tests, now on all nine jobs.

The part worth keeping

This is the entire argument for a build matrix, and it is not thoroughness for its own sake.

"Works on my machine" is a true statement about exactly one row of that matrix. I had declared support for a range I had never once executed. The matrix did not find a rare edge case; it found that two thirds of my stated support was fiction, about ninety seconds after I pushed the workflow.

If your package declares an engines range, run your tests across that range. Otherwise the range is a guess you are asking your users to verify for you.

https://github.com/wiktormalyska/mcp-secrets-runner

1Password's secret masking silently corrupts MCP servers

Wiktor Małyska — Sun, 30 Aug 2026 13:00:01 +0000

I added 1Password support to an MCP secrets runner and the first thing I had to do was turn one of its security features off. Here is why that was the right call.

What op run does

1Password's CLI resolves op:// references and hands the values to a child process:

op run --env-file=./mcp.env -- npx -y @stripe/mcp@latest

It also does something thoughtful on top. It watches the child's output and rewrites anything matching a resolved secret to <concealed by 1Password>. If your program accidentally logs a token, or you are screen sharing, the secret does not leave the machine.

For a normal CLI this is a good default. I would keep it on.

What an MCP server is

An MCP server on the stdio transport speaks JSON-RPC over stdout. Not log lines. A framed protocol stream, where the client parses every byte:

{"jsonrpc":"2.0","id":1,"result":{"tools":[...]}}

stdout is not a place for human-readable output. It is a wire.

The collision

Put those two together. Masking rewrites bytes in a stream that a parser is reading with exact expectations. If a secret value ever appears inside a frame, the frame changes length, and the parse fails.

What makes this genuinely nasty is where it fails. The MCP client reports a protocol error. Nothing in that error mentions 1Password, masking, or secrets. You would go and read your server's serialisation code, which is fine, for a long time.

So the provider passes --no-masking by default, and the README says why in as many words. There is an opt-in flag to turn masking back on for servers that do not use stdio.

The general shape

What I find worth writing down is that nothing here is a bug. Not in 1Password, not in MCP, not in my code.

A security feature assumes it may rewrite a child's output. A wire protocol assumes it owns stdout exclusively. Both assumptions are reasonable in isolation. The failure lives in the space between them, and it is silent, because neither component is in a position to notice the other exists.

Every integration you write has a few of these. They do not show up in either project's issue tracker, because from each side nothing is wrong. They show up in yours.

The practical takeaway: when you wrap a process that speaks a protocol on stdout, audit everything in the chain for the assumption that stdout is for humans. Log prefixes, colour codes, progress bars, and yes, secret masking.

https://www.npmjs.com/package/mcp-secrets-runner

Your .mcp.json probably has a live API key in it

Wiktor Małyska — Fri, 28 Aug 2026 13:00:00 +0000

Nearly every guide to setting up an MCP server tells you to do this:

{
  "mcpServers": {
    "stripe": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp@latest"],
      "env": { "STRIPE_SECRET_KEY": "sk_live_51J..." }
    }
  }
}

That is a live production key sitting in a file that gets committed to repositories, synced between machines, screenshotted for tutorials and pasted into bug reports. I have seen sk_live_ keys in all four.

It is also, in my experience, the single biggest reason MCP stalls at a company's security review. Not the protocol. Not the tooling. The config file.

The obvious fix has its own failure mode

So you wrap the server in your secret manager's CLI instead:

"args": ["run", "--env=prod", "--", "npx", "-y", "@stripe/mcp@latest"]

Better. The key is gone from the file. But those CLIs authenticate with a developer session stored in your OS keyring, and that session expires.

When it does, every MCP server wrapped this way stops starting at the same moment. And the error surfaces in your MCP client, which knows nothing about secret managers or expired logins. You get a generic startup failure on ten servers at once and go looking in entirely the wrong place.

I lost an afternoon to this before the pattern clicked.

Machine identities do not expire

Every serious secret manager has a concept for unattended access: a credential meant for machines rather than humans, with no TTL of its own. Infisical calls it a machine identity, 1Password calls it a service account, Vault calls it AppRole.

The credential is long-lived; what it produces is short-lived. You exchange it for a token at process start, use the token, and never think about it again.

That is the whole idea behind mcp-secrets-runner. It sits between the MCP client and the server, authenticates with a machine credential, fetches the secrets and execs the real server:

{
  "mcpServers": {
    "stripe": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-secrets-runner", "--env=prod", "--path=/mcp",
               "--", "npx", "-y", "@stripe/mcp@latest"]
    }
  }
}

No secret values in the file. No session to renew. The same config works on every machine that has the machine credentials in its environment, which is what makes it safe to commit.

Three backends, three different shapes

The interesting part of building this was that the three supported backends work nothing alike:

Infisical mints a token over HTTPS, then hands off to the Infisical CLI.
1Password hands off to op run, which authenticates itself.
Vault reads the secret over the HTTP API and starts your MCP server directly, with no CLI involved at all.

A provider only has to answer one question: which child process do I start, and what environment does it get. That the three answers look so different is the best evidence I have that the interface is not overfitted to the first one I wrote.

When it does not work

"My MCP server won't start" is almost always one of four things, and an MCP client reports all four identically. So there is a doctor:

$ mcp-secrets-runner doctor --provider=vault

mcp-secrets-runner doctor (provider: vault)

  [ok  ] Node 22.14.0
  [ok  ] instance
         http://127.0.0.1:8200
  [ok  ] AppRole credentials present
  [ok  ] cached token available
  [ok  ] authentication succeeded
         token valid for 20 min

All checks passed.

Missing CLI, missing credentials, wrong instance URL, unreadable secret path. One line each, instead of one opaque failure.

Two details worth stealing

All diagnostics go to stderr. stdout belongs to the MCP protocol. One stray byte there corrupts the JSON-RPC stream and the client reports a parse error pointing nowhere useful.

It fails closed. If credentials are set but authentication fails, the runner exits. The alternative is worse than it sounds: a credential-less CLI invocation opens an interactive browser login, which hangs the MCP server on stdin forever while the client waits.

MIT, zero dependencies, Node 18+.

https://github.com/wiktormalyska/mcp-secrets-runner

Stop Hardcoding Your Portfolio Projects. I Built an API to Turn GitHub into a Headless CMS

Wiktor Małyska — Sun, 22 Mar 2026 13:27:32 +0000

Every time I finished a new side project, I faced the exact same annoying routine:

Open my portfolio repository.
Find the projects.json or hardcoded array.
Manually type in the new project name, description, and tech stack.
Download a screenshot, put it in the public folder, and link it.
Push changes and wait for the deployment.

As developers, we automate everything, yet we still update our portfolios like it's 2010. I got tired of this, so I built a solution: PortfolioAPI.

What is PortfolioAPI?

It’s a simple tool that turns your GitHub repositories into a Headless CMS for your portfolio. Instead of manually updating your frontend code, your portfolio fetches data directly from your GitHub repos via one fast API call.

Live Link: PortfolioAPI

How it works (It takes 2 minutes)

Step 1: Drop a meta.json in your repo
You just create a meta.json file in the root of any public GitHub repository you want to showcase.

{
  "name": "My Awesome Project",
  "description": "A short description shown on the portfolio page.",
  "imageUrl": "[https://raw.githubusercontent.com/your-username/your-repo/main/assets/screenshot.png](https://raw.githubusercontent.com/your-username/your-repo/main/assets/screenshot.png)",
  "websiteUrl": "[https://my-project.example.com](https://my-project.example.com)",
  "technologies": [
    "React",
    "TypeScript",
    "TailwindCSS"
  ]
}

Step 2: Fetch the data in your frontend
Make a single GET request using your API key. The API scans your GitHub, finds all repos with a meta.json, and returns a clean, structured array of your projects.

const fetchProjects = async () => {
  const response = await fetch('[https://api.portfolioapi.wiktormalyska.ovh/projects](https://api.portfolioapi.wiktormalyska.ovh/projects)', {
    headers: {
      'X-API-KEY': 'your_api_key_here'
    }
  });
  const data = await response.json();
  return data; // Boom! Ready to map over in React/Vue/Svelte
};

Why did I build it this way?

Zero Database Needed: Your code lives on GitHub anyway, why not keep its metadata there too?
Always Up to Date: Update the meta.json in your project repo, and your portfolio updates instantly.
Blazing Fast: I implemented server-side caching so the GitHub data is delivered in milliseconds. No unnecessary noise.
Tech Agnostic: It doesn't matter if your portfolio is built in React, Vue, Next.js, or vanilla HTML. It’s just a standard REST API.

What's next?

Right now, the API handles reading GitHub portfolios perfectly. I'm currently working on adding a dedicated Node.js package and an email contact form endpoint to make it an all-in-one backend for developer portfolios.

I’m an indie developer trying to build tools that actually save time. I’d love to hear your feedback. What do you think about managing portfolio content directly from GitHub repos?

Let me know in the comments! 👇

Psst... with code FREETRIAL you can get first month for free! (for first 10 customers)