feat: bump version to 8.1.0 and automate Open VSX publishing

[AnkanSaha]

Summary

This PR bumps the project version to 8.1.0 across all sub-packages (Go, Extension, Documentation) and introduces a new GitHub Actions job to publish the VS Code extension to the Open VSX Registry.

Changes

• CI/CD: Added publish-open-vsx-extension job to release.yml.
• Versioning: Updated VERSION, package.json, package-lock.json, and Go source files to 8.1.0.
• Workflow Improvements: Added sparse-checkout for the extension publishing jobs to save time.
• Metadata: Added GitHub Step Summary for Open VSX publishing status.

Verification

• Ensure OPEN_VSX_PAT is added to GitHub Secrets.
• Verify that the vsix_path output is correctly linked (Note: Fix required for id: build).

[github-actions]

🤖 Review Buddy - General Code Review

👥 Attention: @AnkanSaha

Oye @AnkanSaha! Bhai, version bump kar rahe ho ya koi mahayagya? 8.0.0 se 8.1.0 pe jaane ke liye itna bawasir failaya hai? Matlab automation ke naam pe redundancy ka buffet laga diya hai. Extension ka version lockfile mein 8.0.0 hai aur package.json mein 8.1.0... dono mein breakup ho gaya hai kya? Aur ye workflow mein vsix_path mangwa rahe ho steps.build.outputs se, par build naam ka toh koi step ID hi nahi hai! Kya fook ke code likh rahe ho? Debugging tumhara ghost karega?

Code Quality Score: 3/10. Kaam toh ho jayega, par dhang se nahi.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

⚡ Review Buddy - Performance Analysis

👥 Attention: @AnkanSaha

Bhai, performance ke naam pe tumne GitHub Actions ke runners ka mazaak uda diya hai. Chalo, line-by-line tumhari 'efficiency' ki dhajjiya udate hain:

1. Redundant Build Cycles: publish-vscode-extension mein tum .vsix banate ho. Phir publish-open-vsx-extension mein wapis wahi npm ci aur npx vsce package chalate ho. Kyun? Paisa GitHub ka hai toh kuch bhi karoge? Ek baar build karke artifact upload kyun nahi karte?
2. npm ci ka Overkill: Har job mein npm ci --prefer-offline chalane se achha hai ki tum node_modules ko cache karo ya workspace share karo.
3. Sparse Checkout Paradox: Tumne sparse-checkout: Extension toh daal diya, lekin uske baad bhi dependency installation ka overhead wahi hai.
4. VSIX Re-packaging: .vsix file ek zip hi toh hai. Use ek baar build karo aur dono registry (VS Marketplace & Open VSX) pe push karo. Do baar packaging matlab double CPU cycles aur double time.
5. Step ID Missing: vsix_path: ${{ steps.build.outputs.vsix_path }} likha hai, par id: build gayab hai. GitHub runner output dhoondhte dhoondhte buddha ho jayega par use kuch nahi milega. Empty string pass hogi aur aage ka logic crash karega.
6. Network IO: Har bar npx vsce aur npx ovsx download ho rahe hain. Inhe global install ya caching mein kyun nahi dala?
7. Go Versioning: main.go aur repl.go mein hardcoded strings hain. Runtime pe version print karne ke liye tumne compiler ko static string thama di. Isse performance pe farak nahi padta, par developer ki sanity pe padta hai.
8. Memory Overhead: GitHub runner 7GB RAM deta hai, tumne sirf npm ci mein hi 500MB khaa li hogi bina kisi reuse ke.
9. Concurrency Issues: Agar dono jobs saath mein fail hui, toh tumhara release half-baked reh jayega.
10. Bash inefficiency: VSIX_FILE=$(ls *.vsix | head -1) - Ye kya jugad hai? Agar multiple vsix mil gaye toh?

Recommendation:

• Use actions/upload-artifact in the build job.
• Use actions/download-artifact in the publishing jobs.
• Add id: build to the packaging step.
• Ek single 'Package' job banao jo artifact generate kare, phir parallel 'Publish' jobs chalao.

Example:

jobs:
  package:
    runs-on: ubuntu-latest
    steps:
      - id: build_step
        run: |
          npx vsce package
          echo "path=$(ls *.vsix)" >> $GITHUB_OUTPUT
  publish:
    needs: package
    run: npx ovsx publish ${{ needs.package.outputs.path }}

Isse workflow tez chalega aur GitHub bill kam aayega.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

🔐 Review Buddy - Security Audit

👥 Attention: @AnkanSaha

Security audit mein tumhare haal toh 'Z+ Security' wale hain... matlab zero plus zero.

1. Secret Leakage Potential: npx vsce publish -p ${{ secrets.AZURE_DEVOPS_VS_CODE_EXTENSION_PUBLISH_TOKEN }} - Bhai, command line arguments mein tokens pass karna band karo. Process list (ps aux) mein ye token chamakta hua dikhega.

   • Severity: Medium
   • Remediation: Use Environment Variables instead of CLI flags where possible.

2. Conditional Check Weakness: if: secrets.OPEN_VSX_PAT != '' - Ye check toh theek hai, par Verify Open VSX token step mein tumne exit 0 kar diya hai warning deke. Agar token galat hua toh workflow success dikhayega par publish nahi hoga. Silent failures are the enemy of security.

   • Severity: Low
   • Reference: OWASP CI/CD Security (Insufficent Logging/Monitoring).

3. Permission Over-scoping: Checkout v4 use kar rahe ho, theek hai, par kya workflow ko write permissions ki zaroorat hai? Ensure contents: read is set globally if not needed.

4. Dependency Risks: npm ci chalate waqt tum fixed versions lockfile se le rahe ho, par Extension/package-lock.json mein version 5.2.0 se direct 8.0.0 ho gaya bina package.json ko match kiye. Supply chain attack ka risk tab badhta hai jab lockfiles aur manifests sync mein nahi hote.

5. Path Traversal (Theoretical): VSIX_FILE=$(ls *.vsix | head -1) - Agar koi malicious file runner mein inject ho gayi with .vsix extension, toh tum blindy use publish kar doge. Validate the filename pattern.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

📊 Review Buddy - Code Quality & Maintainability Analysis

👥 Attention: @AnkanSaha

🎯 Overall Benchmark: 35/100 (Poor)

Quality dekh ke toh lag raha hai ki 'Chalta Hai' attitude peak pe hai. SOLID principles ka 'S' bhi nahi dikh raha idhar.

1. Violation of DRY (Don't Repeat Yourself):

   • Version number 8.1.0 tumne 6 jagah likha hai: Documentation/package.json, Extension/package.json, VERSION, main.go, src/repl/repl.go, aur Extension/package-lock.json (jo ki galat hai).
   • Kal ko 8.1.1 karna hua toh kya poore khandan ko bulaoge update karne?
   • Refactoring: Use a single VERSION file and script it. Go files mein -ldflags "-X main.Version=..." use karo build time pe.

2. Workflow Fragility:

   • publish-open-vsx-extension relies on needs: [version-check, publish-vscode-extension]. Agar VS Marketplace failure hua, toh Open VSX bhi ruk jayega. Dono registries independent honi chahiye.
   • Hardcoded namespace AnkanSaha in the summary markdown? Bhai, environment variable use kar lo, thoda professional lagega.

3. Lockfile Desync:

   • Extension/package-lock.json reflects version 8.0.0 while package.json says 8.1.0. Ye toh wahi baat ho gayi ki shaadi ka card 8 tarikh ka hai aur dulha 9 tarikh ko aa raha hai.
   • Severity: High (Can break reproducible builds).

4. Naming Conventions:

   • Job names are okay, but step names like 'Summary' are too generic.

5. Go Code Quality:

   • fmt.Println ke andar ASCII art hardcode kar diya version ke saath. UI/UX achha hai, par maintainability zero hai.

6. CI/CD Logic Gap:

   • vsix_path output define kiya hai par step mein use populate hi nahi kiya. Variable declaration karke bhool gaye? Aise toh variables bhi tumhe bhool jayenge.

7. Documentation:

   • Documentation/package.json ka version bump kiya, par documentation content update hua? Sirf version badhane se documentation nayi nahi ho jati.

8. Technical Debt:

   • sparse-checkout: Extension is a good move, but the rest of the workflow is still monolithic in thought.

Suggested Refactoring for Go:

// main.go
var Version = "development"
func printVersion() {
    fmt.Printf("║ BanglaCode v%s ║\n", Version)
}

And in CI:
go build -ldflags "-X main.Version=${{ needs.version-check.outputs.version }}" -o banglacode.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

💡 Review Buddy - Best Practices & Alternative Suggestions

👥 Attention: @AnkanSaha

Bhai, coding standards follow karna koi paap nahi hai. Ye dekh aur seekh:

1. Versioning Source of Truth

Galti: Multiple files mein manually version change karna.
Sahi Tarika: Ek file rakho aur baaki jagah build script se inject karo.

# Before (Current PR mess)
Extension/package.json -> 8.1.0
main.go -> 8.1.0

# After (Best Practice)
# package.json is the source
VERSION=$(jq -r .version Extension/package.json)
go build -ldflags "-X main.Version=$VERSION"

2. GitHub Actions Artifacts

Galti: Har job mein packaging repeat karna.
Sahi Tarika: Build once, deploy many.

# Before
- name: Package extension (Job 1)
  run: npx vsce package
- name: Package extension (Job 2)
  run: npx vsce package

# After
- name: Upload VSIX
  uses: actions/upload-artifact@v4
  with:
    path: Extension/*.vsix

3. Output Referencing

Galti: steps.build.outputs.vsix_path use karna bina id: build ke.
Sahi Tarika: Always define IDs for steps that provide outputs.

# Before
- name: Build and publish
  run: echo "..."

# After
- name: Build and package
  id: build
  run: |
    npx vsce package
    echo "vsix_path=$(ls *.vsix)" >> $GITHUB_OUTPUT

4. Lockfile Sync

Galti: package-lock.json ko ignore karna.
Sahi Tarika: npm install chalao taaki lockfile update ho jaye version bump ke baad.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

⚠️ Review Buddy - Final Recommendation

👥 Attention: @AnkanSaha

Recommendation: REQUEST CHANGES

Changes chahiye, bhai! Abhi approve nahi kar sakte.

Reasoning:

• Version mismatch: Extension/package-lock.json is at 8.0.0 while package.json is at 8.1.0.
• Workflow bug: Output 'vsix_path' refers to a non-existent step ID 'build'.
• Redundant builds: The workflow packages the extension twice (once for VS Marketplace, once for Open VSX).
• Hardcoded version strings: Version 8.1.0 is repeated in 5+ files, violating DRY principles.
• Insecure token usage: Passing tokens as CLI flags instead of environment variables.

---

📋 Review Checklist for Reviewers:

• Code changes align with the PR description
• No security vulnerabilities introduced
• Performance considerations addressed
• Code follows project conventions
• Tests are adequate (if applicable)
• Documentation updated (if needed)

🎯 Next Steps:

⚠️ Pehle suggestions address karo, phir approve karna.

Generated by Review Buddy | Tone: roast | Language: hinglish

[Copilot]

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.