Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 28 additions & 33 deletions AGENTS.md
Original file line number Diff line number Diff line change
@@ -1,50 +1,47 @@
# Instructions for Agents: Contributing to Open Audio Stack Registry via Command Line
# Instructions for Agents: Contributing via command line

## Fork the Repository
## 1. Setup git repo

Use GitHub CLI to fork the repository:
Check to see if you are inside the repository:

```bash
git status
```

If you see an error message like `fatal: not a git repository`, then use GitHub CLI to fork the repository:

```bash
gh repo fork open-audio-stack/open-audio-stack-core --clone
cd open-audio-stack-core
```

## Setup

Install dependencies:
Ensure you are on the main branch and up-to-date with changes:

```bash
git checkout main
git pull
npm install
```

## Create a Branch
Then continue to step 2.

## 2. Contributing changes

Create and switch to a new branch for your contribution. Use descriptive branch names following these conventions:
Create a new branch for your contribution. Use descriptive branch names following these conventions:

- `feature/feature-name` for new features
- `fix/fix-name` for bug fixes

Example:

```bash
git checkout -b feature/feature-name
```

## Contributing functional changes

Edit TypeScript/JavaScript files in the codebase using your tools. Ensure changes follow the project's coding standards, enforced by Prettier (.prettierrc.json) for code formatting, ESLint (eslint.config.js) for linting, and Vitest (vitest.config.ts) for the test suite.

Then proceed to the Validate Changes, Commit Changes, Push Changes, and Submit Pull Request sections below.
Then proceed to step 3.

## Validate Changes
## 3. Validate Changes

Run formatting, linting, tests and build commands to validate your changes:
Run the check command which will run code formatting, linting, tests and build commands to validate the changes:

```bash
npm run format
npm run lint
npm test
npm run build
npm run check
```

Verify that all tests pass and there are no linting errors.
Expand All @@ -53,10 +50,10 @@ Return a summary of the changes to the user for them to read/review.

Ask user for [Y/N] approval to proceed to Commit Changes, Push Changes and Submit Pull Request.

- If the user answers Yes or Y, continue to Commit Changes, Push Changes and Submit Pull Request steps below.
- If the user answers No or N, ask them what changes they would like to make, and iterate until they are happy with the result, each time asking for approval to continue to next steps.
- If the user answers Yes or Y, continue to step 4.
- If the user answers No or N, ask them what changes they would like to make, and iterate until they are happy with the result, each time asking for approval before continuing to step 4.

## Commit Changes
## 4. Commit, push and pr changes

Stage and commit your changes. Use descriptive commit messages with prefixes following these conventions:

Expand All @@ -70,22 +67,20 @@ git add .
git commit -m "[feature] Feature name. Add descriptive commit message for your changes"
```

## Push Changes

Push the branch to your forked repository:

```bash
git push origin feature/feature-name
git push origin feature/your-contribution-name
```

## Submit Pull Request

Create a pull request using GitHub CLI:

```bash
gh pr create --title "Your PR Title" --body "Description of your changes"
```

## Conclusion
Then proceed to step 5.

## 5. Conclusion

Respond to the user that the contribution has been submitted for review, with the url to the PR for them to monitor updates.
Respond to the user that the contribution has been submitted for review, with the url to the PR for them to view.
2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@
],
"scripts": {
"build": "tsc -p tsconfig.json",
"check": "npm run format && npm run lint && npm run build",
"check": "npm run format && npm run lint && npm run build && npm test",
"dev": "tsx ./src/index.ts",
"format": "prettier . --write",
"lint": "eslint .",
Expand Down
10 changes: 10 additions & 0 deletions specification.md
Original file line number Diff line number Diff line change
Expand Up @@ -245,6 +245,16 @@ Registries can contain different types of packages, more could be added in the f
| Presets | `presets` |
| Projects | `projects` |

### Platform and Architecture Detection

Managers should detect the current architecture as the default platform for installing plugins. However, users should be allowed to override this to install plugins from another architecture when necessary.

The compatibility rules for plugin architectures depend entirely on the Host (DAW). Plugin Managers cannot always rely on the system's "Runtime Platform" (which would be ARM64 for a native app) because the user's DAW might be running in a different mode.

For example, on Windows 11 on Arm devices supporting ARM64EC (Emulation Compatible), if the Plugin Manager is running natively as ARM64, but the DAW is running in emulated x64 mode, installing a native ARM64 plugin will result in the DAW failing to see or load the plugin. In this case, the user should set the Desired Platform to x64 to install x64-compatible plugins.

The best practice is to allow users to manually set a Desired Platform in the manager's configuration, overriding the auto-detected architecture.

### Sync

The purpose of remote syncing is to call multiple registries and aggregate remote packages into a precalculated index/cache, which speeds up any subsequent operations performed by the app. In most cases the manager will use this feature internally and the user will not need to use it directly.
Expand Down
6 changes: 6 additions & 0 deletions src/types/Architecture.ts
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
export enum Architecture {
Arm32 = 'arm32',
Arm64 = 'arm64',
Arm64ec = 'arm64ec',
X32 = 'x32',
X64 = 'x64',
}
Expand All @@ -22,6 +23,11 @@ export const architectures: ArchitectureOption[] = [
value: Architecture.Arm64,
name: 'Advanced RISC Machine - 64-bit',
},
{
description: 'Windows 11 on Arm feature which allows native ARM64 and x64 code within the same process.',
value: Architecture.Arm64ec,
name: 'Advanced RISC Machine - 64-bit - Emulation Compatible',
},
{
description: 'X86 processors are commonly used in desktop computers and laptops.',
value: Architecture.X32,
Expand Down
2 changes: 1 addition & 1 deletion tests/classes/Config.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ test('Set and get value', () => {

test('Get architecture', () => {
const config: Config = new Config();
expect(config.architecture(Architecture.X32)).toEqual(architectures[2]);
expect(config.architecture(Architecture.X32)).toEqual(architectures[3]);
});

test('Get architectures', () => {
Expand Down
2 changes: 1 addition & 1 deletion tests/classes/ConfigLocal.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ test('Config export', () => {

test('Get architecture', () => {
const config: ConfigLocal = new ConfigLocal(CONFIG);
expect(config.architecture(Architecture.X32)).toEqual(architectures[2]);
expect(config.architecture(Architecture.X32)).toEqual(architectures[3]);
});

test('Get architectures', () => {
Expand Down