soulcraft/brainy
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases 335 Packages Wiki Activity Actions

refactor: simplify build system and improve model loading flexibility

Browse source 
- Remove Rollup bundling in favor of direct TypeScript compilation
- Move from bundled models to dynamic model loading with configurable paths
- Add Docker deployment examples and documentation
- Implement robust model loader with fallback mechanisms
- Update storage adapters for better cross-environment compatibility
- Add comprehensive tests for model loading and package installation
- Simplify package.json scripts and remove complex build configurations
- Clean up deprecated demo files and old bundling scripts

BREAKING CHANGE: Models are no longer bundled with the package. They are now loaded dynamically from CDN or custom paths.
This commit is contained in:
David Snelling 2025-08-05 16:09:30 -07:00
parent 89413ebec2
commit 52a43d51d4
51 changed files with 4835 additions and 8007 deletions
Download patch file Download diff file Expand all files Collapse all files

53
docs/development/DEVELOPERS.md
View file

@ -88,37 +88,42 @@ npm run test:core
npm run test:coverage
```
The `test:report` script provides a comprehensive test report showing detailed information about all tests that were run, including test names, execution time, and pass/fail status.
The `test:report` script provides a comprehensive test report showing detailed information about all tests that were
run, including test names, execution time, and pass/fail status.
### Testing Best Practices
When developing and debugging Brainy, follow these testing guidelines:
1. **Use Proper Test Files**: All tests should be written as vitest test files in the `tests/` directory with `.test.ts` or `.spec.ts` extensions.
1. **Use Proper Test Files**: All tests should be written as vitest test files in the `tests/` directory with `.test.ts`
or `.spec.ts` extensions.
2. **Avoid Temporary Debug Files**: Do not create temporary debug files like `debug_test.js`, `reproduce_issue.js`, or similar files in the root directory. These files:
- Clutter the repository
- Are excluded by vitest configuration but remain in the codebase
- Often duplicate functionality already covered by proper tests
2. **Avoid Temporary Debug Files**: Do not create temporary debug files like `debug_test.js`, `reproduce_issue.js`, or
similar files in the root directory. These files:
- Clutter the repository
- Are excluded by vitest configuration but remain in the codebase
- Often duplicate functionality already covered by proper tests
3. **Debugging Approach**: When debugging issues:
- Add temporary test cases to existing test files in the `tests/` directory
- Use `it.only()` or `describe.only()` to focus on specific tests during debugging
- Remove or convert temporary test cases to permanent tests before committing
- Use the existing test setup and utilities in `tests/setup.ts`
- Add temporary test cases to existing test files in the `tests/` directory
- Use `it.only()` or `describe.only()` to focus on specific tests during debugging
- Remove or convert temporary test cases to permanent tests before committing
- Use the existing test setup and utilities in `tests/setup.ts`
4. **Test Organization**:
- Core functionality tests go in `tests/core.test.ts`
- Environment-specific tests go in `tests/environment.*.test.ts`
- Utility function tests go in `tests/vector-operations.test.ts`
- New feature tests should follow the existing naming convention
4. **Test Organization**:
- Core functionality tests go in `tests/core.test.ts`
- Environment-specific tests go in `tests/environment.*.test.ts`
- Utility function tests go in `tests/vector-operations.test.ts`
- New feature tests should follow the existing naming convention
5. **Cleanup**: Always clean up temporary files before committing. The vitest configuration already excludes `*.js` files in the root directory, but they should be deleted rather than left in the repository.
5. **Cleanup**: Always clean up temporary files before committing. The vitest configuration already excludes `*.js`
files in the root directory, but they should be deleted rather than left in the repository.
6. **Test Reporting**: Use the comprehensive test reporting feature when you need detailed information about test execution:
- Run `npm run test:report` to get a verbose report of all tests
- The report includes test names, execution time, and pass/fail status
- This is especially useful for CI/CD pipelines and debugging test failures
6. **Test Reporting**: Use the comprehensive test reporting feature when you need detailed information about test
execution:
- Run `npm run test:report` to get a verbose report of all tests
- The report includes test names, execution time, and pass/fail status
- This is especially useful for CI/CD pipelines and debugging test failures
### Testing All Environments
@ -226,7 +231,9 @@ These optimizations are particularly beneficial for:
## Reporting Issues
We use GitHub issues to track bugs and feature requests. When creating a new issue, please provide detailed information including steps to reproduce, expected behavior, and actual behavior for bugs, or clear use cases and benefits for feature requests.
We use GitHub issues to track bugs and feature requests. When creating a new issue, please provide detailed information
including steps to reproduce, expected behavior, and actual behavior for bugs, or clear use cases and benefits for
feature requests.
## Code Style Guidelines
@ -248,3 +255,7 @@ The README badges are automatically updated during the build process:
- Manually running `node scripts/generate-version.js`
This ensures that the badge always reflects the current version in package.json, even before publishing to npm.
---
Demo references removed: The demo is now maintained in the separate @soulcraft/demos project.