DEV Community: Shubham

I built ParallelEarth, a VS Code extension for organising alternative implementations and recorded check results around Git worktrees.If it fits something you’re covering, I’d appreciate your independent feedback. I’m particularly interested in whether it

Shubham — Fri, 30 Oct 2026 08:57:13 +0000

Shubham

Oct 30

Compare alternative implementations in VS Code with Git worktrees

#webdev #programming #productivity #opensource

3 min read

Compare alternative implementations in VS Code with Git worktrees

Shubham — Fri, 30 Oct 2026 08:56:32 +0000

You have two ways to implement a change. Both look reasonable. Which one should you keep?

Git branches and worktrees give you separate places to experiment. But you still need to run checks, remember which result belongs to which implementation, and explain your decision.

I built ParallelEarth, a VS Code extension that groups alternatives and recorded check results into one experiment.

Here’s a reproducible example using real Git worktrees.

The example: booking reconciliation

The repository includes a small booking-reconciliation fixture with three alternative implementations.

We’ll run the same command against the baseline and two alternatives, leaving the third untested. This demonstrates an important distinction: passing, failing and having no evidence are different states.

Run the demonstration

You’ll need Git, npm and Node.js 22.17 or later.

git clone https://github.com/shubhammaji1/parallel-earth.git
cd parallel-earth
npm install --ignore-scripts
npm run demo

Run these commands from a checkout you trust. The demo builds the project and executes the included fixture checks.

It creates a separate fixture repository, a baseline worktree and three alternative worktrees. Your development checkout’s booking implementation remains unchanged.

Inspect the results

The demo runs:

`node --test test/reconcile.test.cjs`

against the baseline, Earth A and Earth B.

The resulting comparison is:

Version

Outcome

Baseline

PASSED

A — Deduplicate correctly

PASSED

B — Duplicate regression

REGRESSION

C — Not yet checked

NOT_RUN

REGRESSION means the baseline passed while the alternative failed the matching check under compatible recorded fingerprints.

NOT_RUN means no check result was recorded. It doesn’t mean the implementation failed—or that it works.

The fixture is intentionally constructed to demonstrate these outcomes. It isn’t a benchmark or evidence that the extension detects every regression.

Read the evidence

Open:

artifacts/booking-report.md artifacts/booking-report.json

The Markdown report provides a readable comparison. JSON contains retained execution evidence, including recorded command results.

The terminal also prints the location of the generated fixture. Its worktrees remain available for inspection.

Check the implementation, test expectations and command output together. A green command only tells you that the command succeeded; your tests may still miss important behaviour.

Try the same workflow on your project

Install ParallelEarth from the VS Code Marketplace, then:

Run ParallelEarth: Open Home.

Create an experiment from a trusted Git repository and committed revision.

Create named Earths for your alternative approaches.

Open each Earth and make your changes.

Install dependencies independently where needed.

Run matching checks, review the commands and approve execution.

Compare the evidence and export a report.

Earths start from committed code. Your original checkout’s uncommitted files and installed dependencies aren’t automatically copied.

The automated demo uses the project’s core modules. It is separate from this interactive extension workflow.

Why not use worktrees manually?

You absolutely can.

ParallelEarth uses worktrees underneath. Its purpose is to keep the experiment question, alternative implementations, recorded checks and comparison together inside VS Code.

For a straightforward feature, a branch may be enough. This workflow is more useful when you are evaluating competing approaches before choosing one.

Worktrees separate code state; they aren’t security sandboxes. Approved commands run on your machine. Recorded durations are execution details, not performance benchmarks.

Try it and challenge the workflow

Install for VS Code

Find it on Open VSX

Explore the source and report issues

I’d especially appreciate feedback on one question:

Does keeping the alternatives and check evidence together make your decision easier than managing worktrees manually?

I built domo-doctor to catch configuration issues in Domo custom apps — looking for feedback

Shubham — Mon, 26 Oct 2026 06:18:31 +0000

Hey developers! 👋

I work with Domo custom apps and built domo-doctor, an offline-first diagnostic CLI for checking project configuration and source code.

It helps identify issues such as:

Invalid manifests and malformed mappings.

Duplicate dataset or field aliases.

Dataset requests referencing aliases missing from the manifest.

Problems with local AppDB collection declarations.

From your project folder, run:

npx domo-doctor@latest scan

📦 https://www.npmjs.com/package/domo-doctor

It checks your local project. Live permissions and deployed behavior still need testing in Domo.

I’d love feedback from other Domo developers:

Does it work with your project structure?

Are the findings clear and actionable?

Does it flag anything incorrectly?

What recurring issue should it catch next?

If something breaks, share your Node version, OS, and a small sanitized example—please leave out credentials and client data.

I’m the creator. This is an independent community project, unaffiliated with Domo.

I built Tracepath to debug Node.js requests from the terminal

Shubham — Fri, 09 Oct 2026 05:58:58 +0000

A slow API response doesn’t tell you where the time went. Was it application logic, a database query, or a downstream HTTP call?
I built Tracepath to help investigate these questions during local development, with request traces displayed directly in the terminal.
What it does
Tracepath currently supports:

Express request tracing.
Automatic instrumentation of Node’s HTTP/HTTPS request and get calls.
Custom spans around operations you want to measure.
Browser fetch tracing, with additional setup for backend correlation.
A local terminal dashboard showing timings and errors. The local dashboard requires no hosted account or Docker. Your application does need instrumentation. Try it with Express You’ll need Node.js 22.13 or later. Install the SDK and Express:

npm install @tracepath/node express

Start the dashboard in a separate terminal:

npx @tracepath/cli dashboard

Create a bootstrap file so instrumentation initializes before your application loads:
// bootstrap.mjs

import { init } from '@tracepath/node'

init({
  service: 'demo-api',
  dashboard: true,
})

await import('./server.mjs')

Then create the server:
// server.mjs

import express from 'express'
import {
  getTracer,
  tracepathMiddleware,
} from '@tracepath/node'

const app = express()
const tracer = getTracer()

app.use(tracepathMiddleware(tracer))

app.get('/demo', async (_req, res) => {
  await tracer.startActiveSpan('simulate-slow-operation', async () => {
    await new Promise(resolve => setTimeout(resolve, 300))
  })

  res.json({ message: 'Check your terminal dashboard' })
})

app.listen(3000, '127.0.0.1')

Run it:

node bootstrap.mjs

Visit http://127.0.0.1:3000/demo.
The dashboard should show the request and the custom operation taking roughly 300 ms.
This is a minimal development example; see the package documentation for application shutdown and flushing.

What’s still missing?
This is an early release, and there are limits:

Database queries need manual spans; Postgres/MySQL auto-instrumentation isn’t implemented.
Native Node fetch/Undici and HTTP/2 aren’t automatically instrumented.
The local dashboard doesn’t provide persistent trace storage or alerting. One useful piece of feedback I’ve already received is that database spans—with query timing and row counts—would make this much more valuable. I’d like to hear which integrations matter most to other developers. Looking for hands-on feedback If you work with Node.js/Express, try tracing one endpoint and let me know:
Was setup straightforward?
Did the trace help explain where time was spent?
Which missing integration would stop you from using it? Please avoid putting secrets or personal data in custom span names and attributes. Keep the dashboard local.

📦 Node SDK and documentation
🖥️ Terminal dashboard
🌐 Browser SDK