feat: make library self-contained with pre-built binaries for Vercel

[astro-fusion]

• Remove swisseph-v2 from direct dependencies (moved to optional)
• Add platform-specific prebuilt binaries:
  • darwin-arm64 for macOS M1/M2/M3
  • linux-x64 for Vercel/Linux servers
• Implement native-loader.ts for platform detection and binary loading
• Add fallback support for development with swisseph-v2
• Export platform utilities (getPlatformInfo, hasPrebuilds)
• Update README with Vercel deployment section
• Bump version to 0.2.0

This update enables Vercel deployment without native compilation. Closes: native module loading issues on serverless platforms

[gemini-code-assist]

Summary of Changes

Hello @astro-fusion, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the library's deployability and ease of use, particularly for serverless platforms like Vercel. By embedding pre-built native binaries and implementing a robust native module loading mechanism, it removes the common hurdle of native compilation during deployment. This change makes the library more self-contained and developer-friendly, ensuring a smoother experience across various operating systems and deployment targets.

Highlights

• Vercel Compatibility: The library is now designed to work seamlessly on Vercel's serverless environment by including pre-built binaries for linux-x64 and darwin-arm64, eliminating the need for native compilation during deployment.
• Native Module Loading Refactor: A new native-loader.ts module has been introduced to handle platform detection and intelligent loading of native Swiss Ephemeris binaries. It prioritizes pre-built binaries, falls back to node-gyp-build for dynamic compilation, and finally to the swisseph-v2 package as an optional dependency.
• Dependency Management: The swisseph-v2 package has been moved from a direct dependencies to optionalDependencies in package.json, making the core library self-contained while still providing a fallback for development environments.
• Developer Utilities: New utility functions (getPlatformInfo, hasPrebuilds, getSupportedPlatforms) are now exported to help developers debug platform-specific issues and verify pre-built binary availability.
• Documentation and Build Scripts: The README.md has been updated with a dedicated 'Vercel Deployment' section, usage examples, and troubleshooting tips. New scripts (prebuild:linux, copy:darwin-arm64, check-platform) have been added to facilitate pre-built binary management and platform checks.
• Version Bump: The package version has been updated to 0.2.0 to reflect these significant feature additions and improvements.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a significant improvement, making the library self-contained and Vercel-friendly by including pre-built native binaries. The new native loader is well-designed with a robust fallback mechanism, and the documentation updates are clear and helpful for users deploying on serverless platforms. I've provided a few suggestions to improve the build script's debuggability, clarify a troubleshooting step in the README, and refactor a minor redundancy in the path resolution logic. Overall, this is an excellent update that greatly enhances the library's usability.

[gemini-code-assist]

To make troubleshooting easier for users, it would be helpful to provide the full, unambiguous path to the binary within the node_modules directory.

Suggested change

	- Verify prebuilds/linux-x64/swisseph.node exists in node_modules
	- Verify `node_modules/@af/sweph/prebuilds/linux-x64/swisseph.node` exists.

[gemini-code-assist]

Redirecting the output of apt-get and npm install to /dev/null can hide important warnings or errors, making it difficult to debug build failures inside the Docker container. It's better to allow this output to be displayed for better visibility into the build process.

Suggested change

	apt-get install -y -qq python3 make g++ > /dev/null 2>&1 && \
	echo '🔧 Building native module...' && \
	npm install --ignore-scripts > /dev/null 2>&1 && \
	apt-get install -y -qq python3 make g++ && \
	echo '🔧 Building native module...' && \
	npm install --ignore-scripts && \

[gemini-code-assist]

The first two paths in getPrebuildPaths are redundant, as both path.join(__dirname, '..', ...) and path.resolve(__dirname, '..', ...) will point to the same location. You can simplify this by keeping only the path.resolve version, which is slightly more robust, and updating the comment.

Suggested change

	// Standard prebuild location (when running from dist/)
	paths.push(path.join(__dirname, '..', 'prebuilds', platformKey, 'swisseph.node'));
	// When running from src/ during development
	paths.push(path.resolve(__dirname, '..', 'prebuilds', platformKey, 'swisseph.node'));
	// This path resolves correctly whether running from `dist/` or `src/`
	paths.push(path.resolve(__dirname, '..', 'prebuilds', platformKey, 'swisseph.node'));