DEV Community: yao tang

Complete Guide: Publishing VS Code Extensions to Both Marketplaces

yao tang — Mon, 13 Oct 2025 08:04:50 +0000

Introduction

Publishing a VS Code extension involves more than just writing code. This guide covers the complete process of publishing to both the official Visual Studio Marketplace and the open-source Open VSX Registry.

Prerequisites
Preparing Your Extension
Publishing to Visual Studio Marketplace
Publishing to Open VSX Registry
Automating with CI/CD
Best Practices

Prerequisites

Required Tools

# Install vsce (Visual Studio Code Extensions CLI)
npm install -g @vscode/vsce

# Install ovsx (Open VSX CLI)
npm install -g ovsx

Required Accounts

Microsoft Account - for VS Code Marketplace
Azure DevOps Account - for Personal Access Token
Eclipse Foundation Account - for Open VSX
GitHub Account - linked to Eclipse Foundation

Preparing Your Extension

1. Project Structure

Ensure your extension has the proper structure:

my-extension/
├── src/
│   └── extension.ts
├── package.json
├── README.md
├── CHANGELOG.md
├── LICENSE
├── .vscodeignore
└── icon.png (128x128 recommended)

2. Essential package.json Fields

{
  "name": "my-extension",
  "displayName": "My Awesome Extension",
  "description": "A brief description of what your extension does",
  "version": "0.0.1",
  "publisher": "your-publisher-name",
  "author": "Your Name",
  "license": "MIT",
  "icon": "icon.png",
  "repository": {
    "type": "git",
    "url": "https://github.com/username/repo"
  },
  "engines": {
    "vscode": "^1.80.0"
  },
  "categories": [
    "Other"
  ],
  "keywords": [
    "keyword1",
    "keyword2"
  ]
}

3. Create a .vscodeignore File

.vscode/**
.git/**
.gitignore
node_modules/**
src/**
.eslintrc.json
tsconfig.json
**/*.map
**/*.ts
!dist/**

4. Write Quality Documentation

README.md should include:

What the extension does
Features with screenshots/GIFs
Installation instructions
Usage examples
Configuration options
Known issues
Contribution guidelines

CHANGELOG.md format:

# Change Log

## [0.0.1] - 2025-01-15
### Added
- Initial release
- Feature X
- Feature Y

Publishing to Visual Studio Marketplace

Step 1: Create Azure DevOps Organization

Go to https://dev.azure.com/
Sign in with your Microsoft account
Create a new organization (if you don't have one)

Step 2: Generate Personal Access Token (PAT)

Click on your profile icon → User settings → Personal access tokens
Click New Token
Configure:
- Name: VS Code Extension Publishing
- Organization: Select your organization
- Expiration: Custom (set to 1 year or more)
- Scopes: Custom defined → Check Marketplace → Manage
Click Create and copy the token immediately (you won't see it again!)

Step 3: Create Publisher

# Create publisher (first time only)
vsce create-publisher your-publisher-name

Or create manually at: https://marketplace.visualstudio.com/manage

Step 4: Login with vsce

vsce login your-publisher-name
# Enter your Personal Access Token when prompted

Step 5: Package and Publish

# Test packaging first
vsce package

# This creates a .vsix file you can test locally
# Install it in VS Code: Extensions → ... → Install from VSIX

# Publish to marketplace
vsce publish

# Or publish with version bump
vsce publish patch  # 0.0.1 → 0.0.2
vsce publish minor  # 0.0.1 → 0.1.0
vsce publish major  # 0.0.1 → 1.0.0

Step 6: Verify Publication

Go to https://marketplace.visualstudio.com/
Search for your extension
Check that all information displays correctly

Publishing to Open VSX Registry

Step 1: Setup Eclipse Foundation Account

Create account at https://accounts.eclipse.org/
Sign the Eclipse Contributor Agreement (ECA):
- Go to https://accounts.eclipse.org/user/eca
- Read and sign the agreement

Step 2: Link GitHub Account

Go to https://accounts.eclipse.org/user/edit
Find "Social Accounts" section
Connect your GitHub account
Verify the connection is successful

Step 3: Create Namespace on Open VSX

Log in to https://open-vsx.org/ with GitHub
Go to https://open-vsx.org/user-settings/namespaces
Create a namespace (should match your publisher name)
Wait for approval (usually instant if ECA is signed)

Step 4: Generate Access Token

Go to https://open-vsx.org/user-settings/tokens
Click Generate New Token
Give it a description (e.g., "CLI Publishing")
Copy the token immediately

Step 5: Publish with ovsx

# Login (first time only)
ovsx create-namespace your-namespace
# Enter your access token when prompted

# Package the extension (if not already packaged)
vsce package

# Publish to Open VSX
ovsx publish -p YOUR_ACCESS_TOKEN

# Or publish specific file
ovsx publish your-extension-0.0.1.vsix -p YOUR_ACCESS_TOKEN

Step 6: Verify on Open VSX

Visit https://open-vsx.org/ and search for your extension.

Automating with CI/CD

GitHub Actions Example

Create .github/workflows/publish.yml:

name: Publish Extension

on:
  release:
    types: [created]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Build extension
        run: npm run compile

      - name: Package extension
        run: npx vsce package

      - name: Publish to VS Marketplace
        run: npx vsce publish -p ${{ secrets.VSCE_TOKEN }}

      - name: Publish to Open VSX
        run: npx ovsx publish -p ${{ secrets.OVSX_TOKEN }}

Setup GitHub Secrets

Go to your repository → Settings → Secrets and variables → Actions
Add secrets:
- VSCE_TOKEN: Your Azure DevOps PAT
- OVSX_TOKEN: Your Open VSX access token

Best Practices

Version Management

// Use semantic versioning
{
  "version": "MAJOR.MINOR.PATCH"
}

// Example:
// 1.0.0 - Initial stable release
// 1.1.0 - New features, backward compatible
// 1.1.1 - Bug fixes
// 2.0.0 - Breaking changes

Pre-publish Checklist

[ ] Test extension thoroughly in VS Code
[ ] Update CHANGELOG.md
[ ] Update version in package.json
[ ] Update README.md if features changed
[ ] Check all links work
[ ] Verify icon displays correctly (128x128 PNG)
[ ] Run vsce package and test the .vsix locally
[ ] Commit and push all changes
[ ] Create Git tag for version

Security Best Practices

# Never commit tokens to Git
# Add to .gitignore:
echo "*.vsix" >> .gitignore
echo ".env" >> .gitignore

# Store tokens in environment variables
export VSCE_TOKEN="your-token"
export OVSX_TOKEN="your-token"

# Or use a .env file (don't commit!)

Extension Quality Guidelines

Performance
- Minimize activation time
- Use activation events efficiently
- Lazy load heavy dependencies
User Experience
- Provide clear error messages
- Add configuration options
- Include helpful documentation
Compatibility
- Test on multiple VS Code versions
- Support both Windows and Unix line endings
- Consider different VS Code themes

Common Issues and Solutions

Issue: "Publisher not found"

Solution: Create publisher first with vsce create-publisher or via web interface.

Issue: "Missing repository field"

Solution: Add repository to package.json:

"repository": {
  "type": "git",
  "url": "https://github.com/username/repo"
}

Issue: "Icon not found"

Solution:

Ensure icon.png exists in root directory
Use 128x128 PNG format
Reference it in package.json: "icon": "icon.png"

Issue: Open VSX "Must sign Publisher Agreement"

Solution: See my other article on solving this specific issue.

Issue: "Invalid version"

Solution: Use semantic versioning format (X.Y.Z) in package.json.

Updating Your Extension

# 1. Make your changes
# 2. Update CHANGELOG.md
# 3. Test thoroughly

# 4. Bump version and publish
vsce publish patch  # or minor, or major

# 5. Publish to Open VSX
ovsx publish -p YOUR_TOKEN

# 6. Create Git tag
git tag v0.0.2
git push --tags

Useful Commands Reference

# Package without publishing
vsce package

# Publish with specific version
vsce publish 1.0.0

# Unpublish (use carefully!)
vsce unpublish publisher.extension-name

# List all versions
vsce show publisher.extension-name

# Open VSX commands
ovsx get extension-name
ovsx publish package.vsix -p TOKEN
ovsx version

Resources

Conclusion

Publishing VS Code extensions requires setup, but once configured, the process is straightforward. Key points:

Set up accounts and tokens for both marketplaces
Prepare quality documentation
Test thoroughly before publishing
Automate with CI/CD for efficiency
Keep both marketplaces in sync

Remember: Open VSX is important for VS Code forks like VSCodium, Gitpod, and others that don't use the Microsoft Marketplace.

Happy publishing! 🚀

Solving Open VSX "Must log in with Eclipse Foundation account" Error

yao tang — Mon, 13 Oct 2025 07:25:50 +0000

The Problem

When trying to create a namespace on Open VSX to publish VS Code extensions, I encountered this error:

Error: You must log in with an Eclipse Foundation account and sign a Publisher Agreement before publishing any extension.

The confusing part? I had already logged into my Eclipse Foundation account at https://accounts.eclipse.org/, but Open VSX kept redirecting me to GitHub login, and the error persisted.

Understanding the Issue

Here's what I learned:

Open VSX only supports GitHub OAuth login - there's no direct Eclipse Foundation login option on the Open VSX website
Eclipse Foundation account is still required - but it works behind the scenes through account linking
Publisher Agreement (ECA) must be signed - this is separate from just having an account

The Solution

Step 1: Sign the Eclipse Contributor Agreement (ECA)

Go to your Eclipse Foundation account: https://accounts.eclipse.org/
Navigate to the ECA page: https://accounts.eclipse.org/user/eca
Read and sign the Eclipse Contributor Agreement
Alternatively, you can sign it directly at: https://www.eclipse.org/legal/ECA.php

Step 2: Link Your GitHub Account

Go to your Eclipse Foundation account settings: https://accounts.eclipse.org/user/edit
Find the "Social Accounts" or "External Accounts" section
Connect your GitHub account that you use to log into Open VSX
Make sure the connection is successful

Step 3: Wait for Synchronization

After signing the ECA and linking accounts, wait a few minutes (sometimes up to an hour) for the systems to synchronize.

Step 4: Create Your Namespace

Clear your browser cache and cookies for open-vsx.org
Log in to Open VSX with your GitHub account: https://open-vsx.org/
Go to namespace settings: https://open-vsx.org/user-settings/namespaces
Create your namespace - the error should be gone!

Why This Happens

Open VSX uses GitHub for authentication (OAuth), but requires Eclipse Foundation's legal framework for publishing. The connection between these two systems requires:

An Eclipse Foundation account
A signed Eclipse Contributor Agreement (ECA)
Your GitHub account linked to your Eclipse Foundation account

Troubleshooting Tips

If you still see the error after following these steps:

Clear browser data: Remove all cookies and cache for open-vsx.org
Try incognito mode: This ensures no old session data interferes
Wait longer: Sometimes synchronization takes time
Verify the link: Check your Eclipse Foundation account to confirm GitHub is properly linked
Re-sign if needed: If you signed the ECA a long time ago, try signing again

Additional Resources

Conclusion

The key insight is that Open VSX uses GitHub for login but Eclipse Foundation for legal compliance. Once you understand this relationship and properly link your accounts with a signed ECA, publishing extensions becomes straightforward.

Hope this helps others who encounter the same issue! 🚀

Have you encountered similar issues with Open VSX or VS Code extension publishing? Share your experience in the comments!

How to Publish Your First NPM Package: A Complete Guide

yao tang — Wed, 11 Jun 2025 16:54:34 +0000

Publishing your first NPM package can seem daunting, but it's actually straightforward once you know the steps. In this guide, I'll walk you through the entire process, including how to solve common issues like registry configuration problems.

Prerequisites

Node.js and npm installed
A project ready to publish
An NPM account (create one at npmjs.com)

Step 1: Check Package Name Availability

Before you start, make sure your desired package name isn't already taken:

npm search your-package-name

If the name is taken, you have several options:

Use a scoped package: @yourusername/package-name
Choose a different name
Add descriptive prefixes/suffixes

For example, if "testpilot" is taken, you could use "ai-testpilot" or "@yourusername/testpilot".

Step 2: Configure Your package.json

Make sure your package.json has all the required fields:

{
  "name": "your-package-name",
  "version": "1.0.0",
  "description": "What your package does",
  "main": "index.js",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/yourusername/your-repo.git"
  },
  "keywords": ["keyword1", "keyword2"],
  "author": "Your Name",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/yourusername/your-repo/issues"
  },
  "homepage": "https://github.com/yourusername/your-repo#readme"
}

For CLI tools, add a bin field:

{
  "bin": {
    "your-command": "./bin/cli.js"
  }
}

Step 3: Fix Registry Configuration (Important!)

This is where many people get stuck. If you're using a mirror like Taobao or npmmirror, you need to switch back to the official NPM registry for publishing.

Check your current registry:

npm config get registry

If it shows anything other than https://registry.npmjs.org/, fix it:

npm config set registry https://registry.npmjs.org/

Common problematic registries:

https://registry.npmmirror.com/ (Alibaba mirror)
https://registry.npm.taobao.org/ (Taobao mirror)
Company internal registries

Step 4: Login to NPM

npm login

You'll be prompted for:

Username
Password
Email address

Verify you're logged in:

npm whoami

Step 5: Prepare for Publishing

Create .npmignore (optional):

node_modules/
.git/
.DS_Store
*.log
test/
.env

If you're using TypeScript, build first:

npm run build

Test your package locally:

npm pack
npm install -g your-package-name-1.0.0.tgz
# Test your package
npm uninstall -g your-package-name
rm your-package-name-1.0.0.tgz

Step 6: Publish!

npm publish

For scoped packages, make them public:

npm publish --access public

Step 7: Verify Publication

Check on NPM website:
Visit https://npmjs.com/package/your-package-name

Search for your package:

npm search your-package-name

Test installation:

npm install your-package-name

Common Issues and Solutions

"Package name already exists"

Use a scoped package: @yourusername/package-name
Choose a different name
Check if the existing package is abandoned (contact NPM support)

"Public registration is not allowed"

You're trying to publish to a private registry (like CNPM)
Fix your registry configuration (Step 3)

"You do not have permission to publish"

Make sure you're logged in: npm whoami
Check if you're trying to publish to the correct registry
For scoped packages, use --access public

"Avatar not updating"

NPM uses Gravatar for avatars
Link your NPM email to a Gravatar account
Clear browser cache and wait for synchronization

Pro Tips

Version Management: Use semantic versioning (major.minor.patch)
Add a README: Include installation and usage instructions
Keywords: Add relevant keywords for better discoverability
License: Always specify a license (MIT is popular)
Automated Publishing: Consider using GitHub Actions for CI/CD

Updating Your Package

When you need to update:

Make your changes
Update the version in package.json
Run npm publish again

# Quick version bump
npm version patch  # 1.0.0 -> 1.0.1
npm version minor  # 1.0.0 -> 1.1.0
npm version major  # 1.0.0 -> 2.0.0
npm publish

Conclusion

Publishing to NPM is straightforward once you understand the process. The most common stumbling block is registry configuration - always make sure you're pointing to the official NPM registry when publishing.

Your package is now available for the entire Node.js community to use. Congratulations on your first NPM publication! 🎉

Have you published your first NPM package? Share your experience in the comments below!

🐳 NestJS + Docker + PostgreSQL Debugging: Why Is It Trying to Connect as `callustang`?

yao tang — Wed, 28 May 2025 11:04:28 +0000

🧩 Background

While developing a backend project with NestJS + TypeORM + PostgreSQL, I used docker-compose to spin up both the backend service and the database. Although I had successfully created tables and inserted data into the database, the NestJS app kept failing to connect—mysteriously attempting to authenticate as my Mac user, callustang.

Here’s the error log:

[Nest] 75975  - ERROR [TypeOrmModule] Unable to connect to the database. Retrying...
Error: password authentication failed for user "callustang"

But my .env configuration clearly specified:

DB_USER=root

And even in app.module.ts, I logged the DB config:

console.log('DB Config:', {
  host: config.get('DB_HOST'),
  username: config.get('DB_USER'),
  ...
})

Everything looked correct, yet the connection kept failing. 🤯

🕵️ Investigation Path

The core question was: Where is the app actually running, and what database is it trying to connect to?

✅ I checked:

.env had DB_HOST=pgsqldb
docker-compose.yml defined a pgsqldb service correctly
NestJS printed out DB_HOST: 'pgsqldb'
But the logs showed: getaddrinfo ENOTFOUND pgsqldb

❗ The real issue:

The NestJS app was running locally on my Mac, not inside a Docker container.

Your local machine cannot resolve pgsqldb, which is a hostname only available inside Docker’s internal network. Hence, the DB connection failed.

🔧 Solution 1: Run the NestJS App Inside Docker ✅

I created a proper development Dockerfile and ensured the container had essential tools like ps (used by SWC for hot reload).

FROM node:20.14.0-bookworm-slim

RUN apt-get update && apt-get install -y \
  vim curl wget git procps \
  && apt-get clean \
  && rm -rf /var/lib/apt/lists/*

WORKDIR /usr/src/app

COPY package.json package-lock.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["npm", "run", "start:dev"]

In docker-compose.yml, I updated the app service:

services:
  app:
    build:
      context: .
    ports:
      - "4000:4000"
    volumes:
      - .:/usr/src/app
    env_file:
      - .env
    depends_on:
      - pgsqldb
    networks:
      - app-network

Then I rebuilt and started everything:

docker compose down -v
docker compose build --no-cache
docker compose up

Boom! NestJS successfully connected to PostgreSQL inside the container.

🔧 Solution 2: Still want to run NestJS locally?

Then you must change .env to use:

DB_HOST=localhost

That way, your Mac connects to the containerized PostgreSQL via port mapping.

Ensure your pgsqldb service has:

ports:
  - 5432:5432

This works but is not recommended for long-term use, especially in team projects or CI/CD pipelines.

❓ What about `/bin/sh: ps: not found`?

When running npm run start:dev, I saw this error:

Error: Command failed: ps -A -o pid,ppid
/bin/sh: 1: ps: not found

Turns out the Docker image I used (node:bookworm-slim) doesn't include the ps utility. The solution is simple:

RUN apt-get update && apt-get install -y procps

SWC, Nest CLI, and some TypeScript checkers rely on ps to inspect running processes. It’s not critical, but removing the error makes development smoother.

🔒 Should I install `procps` in production?

No.

In production, your command is simply:

"start:prod": "node dist/src/main"

This does not need ps, SWC, or any hot-reloading tools. Keep your prod images lean and secure.

I used a multi-stage Docker build:

# Stage 1: Build
FROM node:20.14.0-bookworm-slim as builder
...
RUN npm run build && npm prune --production

# Stage 2: Runtime
FROM node:20.14.0-bookworm-slim
...
USER node
CMD ["npm", "run", "start:prod"]

🚫 No ps needed. No bloat.

📌 Summary & Lessons Learned

Problem	Cause	Solution
DB connection fails as `callustang`	App is running on the host and defaulting to Mac user	Run the app inside Docker
`ENOTFOUND pgsqldb`	Local machine can't resolve Docker hostname	Either switch to Docker or use `localhost`
`/bin/sh: ps: not found`	Slim image lacks `procps`	Add `apt-get install procps` in Dockerfile
Should prod image include `ps`?	No	Keep it minimal and secure

💬 Have You Run Into This?

Let me know in the comments if you’ve hit similar container vs. host confusion with NestJS, or if you’ve debugged weird Docker DNS issues. If this helped, give it a ❤️, bookmark it, or share it with someone struggling with dev containers!

Complete Git Authentication Troubleshooting Guide

yao tang — Fri, 23 May 2025 06:51:07 +0000

Problem Description

While working with Git for code management, I encountered a classic authentication failure issue:

> git pull --tags origin main
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

This problem typically occurs in the following scenarios:

Switched to a different GitHub account
Previously used email is no longer accessible
Local Git configuration doesn't match the current available account
SSH key configuration issues

Environment Information

Operating System: macOS
Git Version: Standard version
Problem Scenario: Can download GitHub repository content but unable to execute git pull operations
Historical Context: Previously used a different account for commits, that email is no longer available

Complete Solution Workflow

Step 1: Problem Diagnosis

1.1 Check Current Git Configuration

git config --global user.name
git config --global user.email
git remote -v

1.2 Check Repository Status

git status

Issues Identified:

Local repository remote URL points to incorrect user repository
Authentication credentials don't match current available account

Step 2: Attempting SSH Authentication Fix

2.1 Test SSH Connection

ssh -T git@github.com

Result: SSH connection was successful, showing correct username authentication.

2.2 Update Remote Repository URL

git remote set-url origin git@github.com:YourUsername/repository-name.git

2.3 Test Pull Operation

git pull --tags origin main

Result: Still encountering "Connection closed by 140.82.112.4 port 22" error.

Step 3: Switch to HTTPS Authentication (Key Solution)

3.1 Change Remote Repository URL to HTTPS

git remote set-url origin https://github.com/YourUsername/repository-name.git

3.2 Verify URL Update

git remote -v

Should display:

origin  https://github.com/YourUsername/repository-name.git (fetch)
origin  https://github.com/YourUsername/repository-name.git (push)

3.3 Configure Pull Strategy

git config pull.rebase false  # Use merge strategy

3.4 Execute Pull Operation

git pull --tags origin main

Step 4: Resolve History Conflicts

After executing the pull, you may encounter "refusing to merge unrelated histories" error:

fatal: refusing to merge unrelated histories

4.1 Force Merge Unrelated Histories

git pull --tags origin main --allow-unrelated-histories

4.2 Resolve Potential Conflicts

If conflicts occur, follow these steps:

# Check conflict status
git status

# Manually edit conflict files, then after resolving conflicts
git add .
git commit -m "Merge remote and local histories"

Core Solution Points

1. SSH vs HTTPS Selection

SSH Advantages: One-time setup, long-term use, no repeated password entry
HTTPS Advantages: Better network compatibility, more stable in firewall environments
Recommendation: If SSH connections are unstable, switch to HTTPS decisively

2. Authentication Credential Management

When using HTTPS, you need GitHub Personal Access Token, not account password
Token acquisition path: GitHub Settings → Developer settings → Personal access tokens

3. Repository History Merging

When local and remote repository histories are unrelated, use --allow-unrelated-histories parameter
This situation is common when merging independently created local and remote repositories

Prevention Measures

1. Regularly Update Git Configuration

# Ensure using current available email and username
git config --global user.name "CurrentUsername"
git config --global user.email "current-available-email@example.com"

2. Choose Appropriate Authentication Method

Stable network environment: Prioritize SSH
Restricted network environment: Recommend HTTPS
Team collaboration: Standardize authentication methods to reduce issues

3. Backup Important Configurations

# Backup SSH keys
cp ~/.ssh/id_* ~/backup_ssh/

# Record important Git configurations
git config --list > git_config_backup.txt

Common Variant Problems

Problem 1: Permission denied (publickey)

Solution: Regenerate SSH keys and add to GitHub

Problem 2: Repository not found

Solution: Check repository URL and access permissions

Problem 3: Authentication failed

Solution: Update Personal Access Token

Troubleshooting Commands Summary

Essential Diagnostic Commands

# Check current configuration
git config --list
git remote -v
git status

# Test connections
ssh -T git@github.com
git ls-remote origin

# Clear authentication cache (macOS)
git config --global --unset credential.helper
security delete-internet-password -s github.com

Quick Fix Commands

# Switch to HTTPS (most reliable)
git remote set-url origin https://github.com/username/repo.git

# Configure pull strategy
git config pull.rebase false

# Handle unrelated histories
git pull origin main --allow-unrelated-histories

SSH Troubleshooting Commands

# Generate new SSH key
ssh-keygen -t ed25519 -C "your-email@example.com"

# Add to SSH agent
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# View public key
cat ~/.ssh/id_ed25519.pub

Best Practices

1. Authentication Method Selection

For personal projects: SSH is convenient after initial setup
For corporate environments: HTTPS often works better with proxy/firewall
For CI/CD: Use deploy keys or token-based authentication

2. Security Considerations

Regularly rotate Personal Access Tokens
Use minimal required permissions for tokens
Keep SSH private keys secure and backed up

3. Team Workflow

Document authentication methods used by the team
Standardize on one method when possible
Provide clear setup instructions for new team members

Conclusion

The root causes of this problem were multifold:

Incorrect remote repository URL - Pointing to wrong user repository
Unstable SSH connection - Network environment causing SSH protocol connection failures
Unrelated history records - Local and remote repositories created independently, lacking common ancestors

Final Solution:

Switch to HTTPS protocol for authentication
Use --allow-unrelated-histories to merge independent histories
Configure appropriate pull strategy

This systematic troubleshooting and resolution approach can be applied to most Git authentication-related problems.

Additional Resources

This document is based on actual problem-solving process, applicable to macOS and Linux environments. Windows environment commands may vary slightly.

😵‍💫 Integrating Alibaba DeepSeek AI in a Frontend Project — Why `netlify dev` Breaks Streaming and How to Fix It

yao tang — Fri, 18 Apr 2025 05:37:23 +0000

🧾 Background

While integrating the Alibaba Cloud DeepSeek Assistant API into a frontend project, I wanted real-time AI responses via fetch + stream (ReadableStream). Backend used Express to call DashScope’s streaming endpoint with X-DashScope-SSE: enable, and the frontend expected to receive incremental AI tokens like a chat assistant.

This setup worked perfectly in production.

But in local development with netlify dev?

❌ Streaming completely failed, frontend received nothing, and eventually crashed with:

 net::ERR_EMPTY_RESPONSE

🧨 Problem Summary

Even though the backend successfully received and printed streaming chunks like:

data: {"output":{"text":"Hello"}}

The frontend never got them. Instead:

fetch().body.getReader().read() was never triggered
The browser hung waiting for data
Connection dropped with ERR_EMPTY_RESPONSE

🔍 Root Cause

❌ Suspected Issue	Explanation
Backend forgot `res.end()`	Nope — it's there
Streaming from DashScope failed	Nope — chunks are printed in the backend logs
✅ `netlify dev` local proxy strips streaming	✔️ Yes — this is the real issue

The Netlify CLI (netlify dev) emulates serverless locally, but its internal proxy does not support chunked transfer encoding, which is required for streaming with res.write().

✅ Solution: Bypass Netlify CLI, Run Express Locally

✅ Step 1: Run your backend manually

ts-node src/server.ts

Make sure your Express server listens on a custom port (e.g. 3001):

app.listen(3001, '0.0.0.0', () => {
  console.log('Running at http://localhost:3001');
});

✅ Step 2: Configure frontend proxy (Vite)

// vite.config.ts
server: {
  proxy: {
    '/chat': {
      target: 'http://localhost:3001',
      changeOrigin: true,
    },
  },
}

Now your frontend code still calls /chat, but under the hood it hits your local Express server instead of the broken netlify dev proxy.

✅ Step 3: Make sure your backend properly streams

externalRes.on('data', (chunk) => {
  res.write(chunk); // Stream directly to frontend
});

externalRes.on('end', () => {
  res.end(); // Always close stream
});

💡 Use res.setHeader('Content-Type', 'text/event-stream') for best results if you’re mimicking SSE.

✅ Alternative: Deploy to Netlify

Deployed Netlify Functions do support streaming!

netlify deploy --prod

But don't rely on local dev for anything stream-based.

🧠 Summary

Method	Streaming Supported?	Use Case
`netlify dev`	❌ No	❌ Never use for streaming/debugging SSE
`ts-node` + Express	✅ Yes	✅ Local dev (DeepSeek, OpenAI, etc.)
Deployed Netlify	✅ Yes	✅ Production use with DeepSeek or DashScope

📝 Takeaway

If you're building real-time chat UIs, AI copilots, or stream-based assistants using Alibaba DeepSeek, OpenAI, or similar APIs:

⚠️ Don't use netlify dev during development.

✅ Use Express locally + Vite proxy for a reliable streaming experience.

DEV Community: yao tang

Complete Guide: Publishing VS Code Extensions to Both Marketplaces

Introduction

Table of Contents

Prerequisites

Required Tools

Required Accounts

Preparing Your Extension

1. Project Structure

2. Essential package.json Fields

3. Create a .vscodeignore File

4. Write Quality Documentation

Publishing to Visual Studio Marketplace

Step 1: Create Azure DevOps Organization

Step 2: Generate Personal Access Token (PAT)

Step 3: Create Publisher

Step 4: Login with vsce

Step 5: Package and Publish

Step 6: Verify Publication

Publishing to Open VSX Registry

Step 1: Setup Eclipse Foundation Account

Step 2: Link GitHub Account

Step 3: Create Namespace on Open VSX

Step 4: Generate Access Token

Step 5: Publish with ovsx

Step 6: Verify on Open VSX

Automating with CI/CD

GitHub Actions Example

Setup GitHub Secrets

Best Practices

Version Management

Pre-publish Checklist

Security Best Practices

Extension Quality Guidelines

Common Issues and Solutions

Issue: "Publisher not found"

Issue: "Missing repository field"

Issue: "Icon not found"

Issue: Open VSX "Must sign Publisher Agreement"

Issue: "Invalid version"

Updating Your Extension

Useful Commands Reference

Resources

Conclusion

Solving Open VSX "Must log in with Eclipse Foundation account" Error

The Problem

Understanding the Issue

The Solution

Step 1: Sign the Eclipse Contributor Agreement (ECA)

Step 2: Link Your GitHub Account

Step 3: Wait for Synchronization

Step 4: Create Your Namespace

Why This Happens

Troubleshooting Tips

Additional Resources

Conclusion

How to Publish Your First NPM Package: A Complete Guide

Prerequisites

Step 1: Check Package Name Availability

Step 2: Configure Your package.json

Step 3: Fix Registry Configuration (Important!)

Step 4: Login to NPM

Step 5: Prepare for Publishing

Step 6: Publish!

Step 7: Verify Publication

Common Issues and Solutions

"Package name already exists"

"Public registration is not allowed"

"You do not have permission to publish"

"Avatar not updating"

Pro Tips

Updating Your Package

Conclusion

🐳 NestJS + Docker + PostgreSQL Debugging: Why Is It Trying to Connect as `callustang`?

🧩 Background

🕵️ Investigation Path

✅ I checked:

❗ The real issue:

🔧 Solution 1: Run the NestJS App Inside Docker ✅

🔧 Solution 2: Still want to run NestJS locally?

❓ What about `/bin/sh: ps: not found`?

🔒 Should I install `procps` in production?