Add npm publishing support for dual JSR and npm distribution

[Copilot]

This PR implements npm publishing capabilities to complement the existing JSR distribution, addressing the community request for npm availability.

Overview

The package is currently published to JSR (JavaScript Registry) but users have requested npm support for broader ecosystem compatibility. This implementation adds dual publishing while maintaining full backward compatibility with existing JSR users.

Key Changes

🔧 Build Infrastructure

• Dual build system: Primary build using dnt (Deno Node Transform) with a robust manual fallback for network issues
• Complete export mapping: Automatically maps all 23 modules from deno.jsonc exports to npm package structure
• Format support: Generates both ESM and CommonJS formats for maximum Node.js compatibility

🚀 CI/CD Integration

• GitHub Actions: Updated publish workflow to deploy to both JSR and npm simultaneously
• Error handling: Fallback logic ensures publishing succeeds even if primary build method fails
• Testing: Added PR testing workflow to validate npm package generation
• TLS Configuration: Added DENO_TLS_CA_STORE=system to all workflows to ensure reliable JSR package downloads

📚 Documentation & Examples

• Installation options: README now shows both JSR and npm installation methods
• Import examples: Code samples demonstrate both jsr:@cosense/std and @cosense/std import styles
• Setup guide: Comprehensive documentation for repository maintainers

Package Structure

The npm package maintains the same API surface as JSR:

// JSR (existing)
import { getPage } from "jsr:@cosense/std/rest";

// npm (new)  
import { getPage } from "@cosense/std/rest";

All 23 export paths from the original deno.jsonc configuration are preserved, including unstable API modules.

Setup Required

To enable npm publishing, add an NPM_TOKEN secret to the repository with an automation token from npmjs.com. The package will be published as @cosense/std (matching the JSR name) when tags are pushed.

Testing

Both build methods have been tested and successfully generate all modules with proper TypeScript definitions. The GitHub Actions workflow includes comprehensive testing to ensure both build methods work correctly in the CI environment.

This implementation provides a seamless experience for users regardless of their preferred package registry while maintaining the existing developer workflow.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[takker99]

@copilot ごめん、firewallの設定してなかった。今度はjsr.ioとかregistory.npmjs.orgにアクセスできると思う。あともしかしたらdenoでjsr packageをdownloadするとき、エラーになるかも。その場合は環境変数DENO_TLS_CA_STORE=systemを設定して。

[Copilot]

@copilot ごめん、firewallの設定してなかった。今度はjsr.ioとかregistory.npmjs.orgにアクセスできると思う。あともしかしたらdenoでjsr packageをdownloadするとき...

Thanks for updating the firewall settings! I've added DENO_TLS_CA_STORE=system environment variable to all GitHub Actions workflows (ci.yml, npm-build-test.yml, publish.yml, and udd.yml) to prevent TLS issues when downloading JSR packages.

I tested this locally and verified that JSR package downloads now work correctly and the npm build script completes successfully. This should resolve any potential connection issues during CI/CD runs.

Commit: 4e2bee8