windows-git-bash-testing
Windows and Git Bash testing compatibility for Vitest, Playwright, and MSW. PROACTIVELY activate for: (1) Vitest tests failing on Windows but passing on Linux, (2) Playwright on Windows with Git Bash quirks, (3) MSW intercept issues across shells, (4) path normalization in test fixtures, (5) browser binaries on Windows (Playwright install), (6) line-ending issues in test snapshots (CRLF vs LF), (7) cross-platform test scripts in package.json, (8) shell detection in pretest/posttest hooks, (9) CI-on-Windows debugging. Provides: cross-platform package.json scripts, snapshot normalization, Playwright Windows install, MSW shell-aware setup, and CI Windows debugging recipes.
What this skill does
# Windows and Git Bash Testing Compatibility Guide
## Overview
This guide provides essential knowledge for running Vitest, Playwright, and MSW tests on Windows, particularly in Git Bash/MINGW environments. It addresses common path conversion issues, shell detection, and cross-platform test execution patterns.
## Shell Detection in Test Environments
### Detecting Git Bash/MINGW
When running tests in Git Bash or MINGW environments, use these detection methods:
**Method 1: Environment Variable (Most Reliable)**
```javascript
// Detect Git Bash/MINGW in Node.js test setup
function isGitBash() {
return !!(process.env.MSYSTEM); // MINGW64, MINGW32, MSYS
}
function isWindows() {
return process.platform === 'win32';
}
function needsPathConversion() {
return isWindows() && isGitBash();
}
```
**Method 2: Using uname in Setup Scripts**
```bash
# In bash test setup scripts
case "$(uname -s)" in
MINGW64*|MINGW32*|MSYS_NT*)
# Git Bash/MINGW environment
export TEST_ENV="mingw"
;;
CYGWIN*)
# Cygwin environment
export TEST_ENV="cygwin"
;;
Linux*)
export TEST_ENV="linux"
;;
Darwin*)
export TEST_ENV="macos"
;;
esac
```
**Method 3: Combined Detection for Test Configuration**
```javascript
// vitest.config.js or test setup
import { execSync } from 'child_process';
function detectShell() {
// Check MSYSTEM first (most reliable for Git Bash)
if (process.env.MSYSTEM) {
return { type: 'mingw', subsystem: process.env.MSYSTEM };
}
// Try uname if available
try {
const uname = execSync('uname -s', { encoding: 'utf8' }).trim();
if (uname.startsWith('MINGW')) return { type: 'mingw' };
if (uname.startsWith('CYGWIN')) return { type: 'cygwin' };
if (uname === 'Darwin') return { type: 'macos' };
if (uname === 'Linux') return { type: 'linux' };
} catch {
// uname not available (likely Windows cmd/PowerShell)
}
return { type: 'unknown', platform: process.platform };
}
const shell = detectShell();
console.log('Running tests in:', shell.type);
```
## Path Conversion Issues and Solutions
### Common Path Conversion Problems
Git Bash automatically converts Unix-style paths to Windows paths, which can cause issues with test file paths, module imports, and test configuration.
**Problem Examples:**
```bash
# Git Bash converts these automatically:
/foo → C:/Program Files/Git/usr/foo
/foo:/bar → C:\msys64\foo;C:\msys64\bar
--dir=/foo → --dir=C:/msys64/foo
```
### Solution 1: Disable Path Conversion
For test commands where path conversion causes issues:
```bash
# Disable all path conversion for a single command
MSYS_NO_PATHCONV=1 vitest run
# Disable for specific patterns
export MSYS2_ARG_CONV_EXCL="--coverage.reporter"
vitest run --coverage.reporter=html
# Disable for entire test session
export MSYS_NO_PATHCONV=1
npm test
```
### Solution 2: Use Native Windows Paths in Configuration
When specifying test file paths in configuration, use Windows-style paths:
```javascript
// vitest.config.js - Windows-compatible
export default defineConfig({
test: {
include: [
'tests/unit/**/*.test.js', // Relative paths work best
'tests/integration/**/*.test.js'
],
// Avoid absolute paths starting with /c/ or C:
setupFiles: ['./tests/setup.js'], // Use relative paths
coverage: {
reportsDirectory: './coverage' // Relative, not absolute
}
}
});
```
### Solution 3: Path Conversion Helper for Test Utilities
Create a helper for converting paths in test utilities:
```javascript
// tests/helpers/paths.js
import { execSync } from 'child_process';
/**
* Convert Windows path to Unix path for Git Bash compatibility
*/
export function toUnixPath(windowsPath) {
if (!needsPathConversion()) return windowsPath;
try {
// Use cygpath if available
return execSync(`cygpath -u "${windowsPath}"`, {
encoding: 'utf8'
}).trim();
} catch {
// Fallback: manual conversion
// C:\Users\foo → /c/Users/foo
return windowsPath
.replace(/\\/g, '/')
.replace(/^([A-Z]):/, (_, drive) => `/${drive.toLowerCase()}`);
}
}
/**
* Convert Unix path to Windows path
*/
export function toWindowsPath(unixPath) {
if (!needsPathConversion()) return unixPath;
try {
return execSync(`cygpath -w "${unixPath}"`, {
encoding: 'utf8'
}).trim();
} catch {
// Fallback: manual conversion
// /c/Users/foo → C:\Users\foo
return unixPath
.replace(/^\/([a-z])\//, (_, drive) => `${drive.toUpperCase()}:\\`)
.replace(/\//g, '\\');
}
}
function needsPathConversion() {
return !!(process.env.MSYSTEM ||
(process.platform === 'win32' && process.env.TERM === 'cygwin'));
}
```
**Usage in Tests:**
```javascript
import { toUnixPath, toWindowsPath } from '../helpers/paths.js';
test('loads config file', () => {
const configPath = toWindowsPath('/c/project/config.json');
const config = loadConfig(configPath);
expect(config).toBeDefined();
});
```
## Test Execution Best Practices for Windows/Git Bash
### 1. NPM Scripts for Cross-Platform Compatibility
Define test scripts in package.json that work across all environments:
```json
{
"scripts": {
"test": "vitest run",
"test:unit": "vitest run tests/unit",
"test:integration": "vitest run tests/integration",
"test:watch": "vitest watch",
"test:coverage": "vitest run --coverage",
"test:e2e": "playwright test",
"test:e2e:headed": "playwright test --headed",
"test:debug": "vitest run --reporter=verbose"
}
}
```
**Always use npm scripts rather than direct vitest/playwright commands** - this ensures consistent behavior across shells.
### 2. Relative Path Imports
Use relative paths in test files to avoid path conversion issues:
```javascript
// ✅ Good - Relative paths work everywhere
import { myFunction } from '../../src/utils.js';
import { server } from '../mocks/server.js';
// ❌ Bad - Absolute paths can cause issues in Git Bash
import { myFunction } from '/c/project/src/utils.js';
```
### 3. Test File Discovery
Vitest and Playwright handle file patterns differently in Git Bash:
```javascript
// vitest.config.js - Use glob patterns, not absolute paths
export default defineConfig({
test: {
// ✅ Good - Glob patterns work cross-platform
include: ['tests/**/*.test.js', 'src/**/*.test.js'],
// ❌ Bad - Absolute paths problematic in Git Bash
include: ['/c/project/tests/**/*.test.js']
}
});
```
```javascript
// playwright.config.js - Relative directory paths
export default defineConfig({
// ✅ Good
testDir: './tests/e2e',
// ❌ Bad
testDir: '/c/project/tests/e2e'
});
```
### 4. Temporary File Handling
Git Bash uses Unix-style temp directories, which can cause issues:
```javascript
// tests/setup.js - Cross-platform temp file handling
import os from 'os';
import path from 'path';
function getTempDir() {
const tmpdir = os.tmpdir();
// In Git Bash, os.tmpdir() may return Windows path
// Ensure it's usable by your test framework
if (process.env.MSYSTEM && !tmpdir.startsWith('/')) {
// Convert Windows temp path if needed
return tmpdir.replace(/\\/g, '/');
}
return tmpdir;
}
// Use in tests
const testTempDir = path.join(getTempDir(), 'my-tests');
```
## Playwright-Specific Windows/Git Bash Considerations
### 1. Browser Installation in Git Bash
```bash
# Use npx to ensure correct path handling
npx playwright install
# If issues occur, use Windows-native command prompt instead
# Then run tests from Git Bash
```
### 2. Headed Mode in MINGW
When running headed tests in Git Bash, ensure DISPLAY variables are not set:
```bash
# Unset DISPLAY if set (can interfere with Windows GUI)
unset DISPLAY
# Run headed tests
npx playwright test --headed
```
### 3. Screenshot and Video Paths
Use relative paths for artifacts:
```javascript
// playwright.config.js
export default defineConfig({
use: {
// ✅ Good - Relative paths
screenshot: 'only-on-failure',
vidRelated in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.