From 5665eb460fcf52117bd3ac11e0f4f6c53cf70e39 Mon Sep 17 00:00:00 2001 From: Kim T Date: Mon, 26 Jan 2026 22:38:24 -0800 Subject: [PATCH] [feature] Add arm64ec architecture support and update Manager specification --- AGENTS.md | 61 ++++++++++++++----------------- package.json | 2 +- specification.md | 10 +++++ src/types/Architecture.ts | 6 +++ tests/classes/Config.test.ts | 2 +- tests/classes/ConfigLocal.test.ts | 2 +- 6 files changed, 47 insertions(+), 36 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index e560265..3056abb 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -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. @@ -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: @@ -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. diff --git a/package.json b/package.json index 989f935..5b35dcc 100644 --- a/package.json +++ b/package.json @@ -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 .", diff --git a/specification.md b/specification.md index a978a99..b177d98 100644 --- a/specification.md +++ b/specification.md @@ -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. diff --git a/src/types/Architecture.ts b/src/types/Architecture.ts index 6f012f0..f0d6920 100644 --- a/src/types/Architecture.ts +++ b/src/types/Architecture.ts @@ -1,6 +1,7 @@ export enum Architecture { Arm32 = 'arm32', Arm64 = 'arm64', + Arm64ec = 'arm64ec', X32 = 'x32', X64 = 'x64', } @@ -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, diff --git a/tests/classes/Config.test.ts b/tests/classes/Config.test.ts index 57c2a98..da101ec 100644 --- a/tests/classes/Config.test.ts +++ b/tests/classes/Config.test.ts @@ -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', () => { diff --git a/tests/classes/ConfigLocal.test.ts b/tests/classes/ConfigLocal.test.ts index 22cfe48..a35c16e 100644 --- a/tests/classes/ConfigLocal.test.ts +++ b/tests/classes/ConfigLocal.test.ts @@ -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', () => {