@api-client/core 0.20.10 → 0.21.1

package/tests/client/src/platform.spec.ts

@@ -0,0 +1,14 @@
+import { test } from '@pawel-up/lupa/testing'
+import * as Platform from '../../../src/Platform.js'
+
+test('hasFormData is true', ({ assert }) => {
+  assert.isTrue(Platform.hasFormData)
+})
+
+test('hasBlob is true', ({ assert }) => {
+  assert.isTrue(Platform.hasBlob)
+})
+
+test('hasBuffer is false', ({ assert }) => {
+  assert.isFalse(Platform.hasBuffer)
+})

package/tests/unit/mocking/current/File.spec.ts

@@ -1,6 +1,6 @@
 import { test } from '@japa/runner'
 import { File } from '../../../../src/mocking/lib/File.js'
-import { FolderKind, ProjectKind } from '../../../../src/models/kinds.js'
+import { FolderKind, ApiFileKind } from '../../../../src/models/kinds.js'
 import type { FileSchema } from '../../../../src/models/store/File.js'
 
 test.group('File', (group) => {
@@ -19,11 +19,11 @@ test.group('File', (group) => {
 
   test('file(init) allows overriding properties', ({ assert }) => {
     const init: Partial<FileSchema> = {
-      kind: ProjectKind,
+      kind: ApiFileKind,
       info: { name: 'My Project' },
     }
     const result = fileMock.file(init)
-    assert.equal(result.kind, ProjectKind)
+    assert.equal(result.kind, ApiFileKind)
     assert.equal(result.info.name, 'My Project')
   })
 
@@ -35,12 +35,12 @@ test.group('File', (group) => {
 
   test('files(size, init) allows overriding properties', ({ assert }) => {
     const init: Partial<FileSchema> = {
-      kind: ProjectKind,
+      kind: ApiFileKind,
     }
     const result = fileMock.files(3, init)
     assert.lengthOf(result, 3)
     result.forEach((item) => {
-      assert.equal(item.kind, ProjectKind)
+      assert.equal(item.kind, ApiFileKind)
     })
   })
 

package/tests/unit/mocking/current/Trash.spec.ts

@@ -1,6 +1,6 @@
 import { test } from '@japa/runner'
 import { Trash } from '../../../../src/mocking/lib/Trash.js'
-import { ProjectKind } from '../../../../src/models/kinds.js'
+import { ApiFileKind } from '../../../../src/models/kinds.js'
 import type { TrashEntry } from '../../../../src/models/TrashEntry.js'
 
 test.group('Trash', (group) => {
@@ -23,11 +23,11 @@ test.group('Trash', (group) => {
   test('trashEntry(init) allows overriding properties', ({ assert }) => {
     const init: Partial<TrashEntry> = {
       key: 'custom-key',
-      kind: ProjectKind,
+      kind: ApiFileKind,
     }
     const result = trash.trashEntry(init)
     assert.equal(result.key, 'custom-key')
-    assert.equal(result.kind, ProjectKind)
+    assert.equal(result.kind, ApiFileKind)
   })
 
   test('trashEntries() returns a list', ({ assert }) => {
@@ -38,12 +38,12 @@ test.group('Trash', (group) => {
 
   test('trashEntries(size, init) allows overriding properties', ({ assert }) => {
     const init: Partial<TrashEntry> = {
-      kind: ProjectKind,
+      kind: ApiFileKind,
     }
     const result = trash.trashEntries(3, init)
     assert.lengthOf(result, 3)
     result.forEach((item) => {
-      assert.equal(item.kind, ProjectKind)
+      assert.equal(item.kind, ApiFileKind)
     })
   })
 })

package/tests/unit/modeling/RuntimeApiModel.spec.ts

@@ -1,10 +1,10 @@
 /* eslint-disable @typescript-eslint/no-unused-vars */
 import { test } from '@japa/runner'
 import { ApiModel } from '../../../src/modeling/ApiModel.js'
-import { RuleEvaluator, RuntimeApiModel, type RuntimeApiModelSchema } from '../../../src/modeling/RuntimeApiModel.js'
+import { RuntimeApiModel, type RuntimeApiModelSchema } from '../../../src/modeling/RuntimeApiModel.js'
 import { DataDomain } from '../../../src/modeling/DataDomain.js'
 import { SemanticType } from '../../../src/modeling/Semantics.js'
-import { AccessRule, AccessRuleExecutionPhase } from '../../../src/modeling/index.js'
+import { AccessRuleExecutionPhase } from '../../../src/modeling/index.js'
 
 test.group('RuntimeApiModel', () => {
   test('initializes from schema', ({ assert }) => {
@@ -26,7 +26,17 @@ test.group('RuntimeApiModel', () => {
     const schema: RuntimeApiModelSchema = {
       ...baseModel.toJSON(),
       routingMap: {
-        GET: [{ path: '/users/{id}', lookup: { exposedEntityKey: expose.key, actionKind: 'read' } }],
+        GET: [
+          {
+            path: '/users/{id}',
+            lookup: {
+              exposedEntityKey: expose.key,
+              actionKind: 'read',
+              exposedEntityName: '',
+              params: [],
+            },
+          },
+        ],
       },
     }
 
@@ -415,7 +425,17 @@ test.group('RuntimeApiModel', () => {
     const schema: RuntimeApiModelSchema = {
       ...baseModel.toJSON(),
       routingMap: {
-        GET: [{ path: '/test', lookup: { exposedEntityKey: entity.key, actionKind: 'read' } }],
+        GET: [
+          {
+            path: '/test',
+            lookup: {
+              exposedEntityKey: entity.key,
+              actionKind: 'read',
+              exposedEntityName: '',
+              params: [],
+            },
+          },
+        ],
       },
     }
 

package/tests/unit/models/File/createFileCapabilities.spec.ts

@@ -1,5 +1,6 @@
 import { test } from '@japa/runner'
-import { File, Folder, Project, type CapabilitiesSchema, type PermissionRole } from '../../../../src/models/index.js'
+import { File, Folder, type CapabilitiesSchema, type PermissionRole } from '../../../../src/models/index.js'
+import { DomainFile } from '../../../../src/modeling/DomainFile.js'
 
 test.group('File.createFileCapabilities()', () => {
   test('{$i} correctly sets file capabilities')
@@ -66,7 +67,7 @@ test.group('File.createFileCapabilities()', () => {
       ['canMove', 'owner', true],
     ])
     .run(({ assert }, row) => {
-      const file = new Project()
+      const file = new DomainFile()
       const result = File.createFileCapabilities(file, row[1] as PermissionRole)
       const key = row[0] as keyof CapabilitiesSchema
       assert.strictEqual(result[key], row[2])

package/tsconfig.build.json

@@ -0,0 +1,8 @@
+{
+  "extends": "./tsconfig.json",
+  "compilerOptions": {
+    "outDir": "./build"
+  },
+  "include": ["src/**/*.ts"],
+  "exclude": ["node_modules", "build", "coverage", "amf-models", "docs", "scripts"]
+}

package/RELEASE.md

@@ -1,163 +0,0 @@
-# Release Guide
-
-This project uses an **automated release system** with conventional commits and GitHub Actions. Releases are automatically created when changes are merged to the main branch.
-
-## 🚀 Automated Releases (Recommended)
-
-### How It Works
-
-1. **Push to main branch** (usually via PR merge)
-2. **Tests run automatically** to ensure quality
-3. **System analyzes commit messages** since the last release
-4. **Release type is determined automatically:**
-   - `major` - if commits contain "breaking:" or "!:"
-   - `minor` - if commits contain "feat:" (new features)
-   - `patch` - for all other changes (bug fixes, docs, etc.)
-5. **Release is created automatically** with changelog and npm publish
-
-### Commit Message Examples
-
-```bash
-# Major release (breaking changes)
-git commit -m "feat!: remove deprecated API"
-git commit -m "feat: new system
-
-BREAKING CHANGE: Old methods no longer work"
-
-# Minor release (new features)
-git commit -m "feat: add OAuth2 support"
-git commit -m "feat(auth): implement JWT tokens"
-
-# Patch release (bug fixes, docs, etc.)
-git commit -m "fix: resolve memory leak"
-git commit -m "docs: update API documentation"
-git commit -m "chore: update dependencies"
-```
-
-### What Happens Automatically
-
-1. ✅ Tests run to ensure everything works
-2. ✅ Version is bumped in `package.json`
-3. ✅ Changes are committed with conventional commit message
-4. ✅ Git tag is created (e.g., `v1.2.3`)
-5. ✅ GitHub release is created with automated changelog
-6. ✅ Package is published to npm
-
-## 🔧 Manual Releases (Fallback)
-
-If you need to create a release manually (e.g., for hotfixes or special releases):
-
-### Option 1: Use the release script
-
-```bash
-# Create a patch release (bug fixes)
-npm run release:patch
-
-# Create a minor release (new features)
-npm run release:minor
-
-# Create a major release (breaking changes)
-npm run release:major
-
-# Or use the default (patch)
-npm run release
-```
-
-### Option 2: Manual tag creation
-
-```bash
-npm run build
-# Update version in package.json
-npm version patch --no-git-tag-version
-
-# Commit the change
-git add package.json
-git commit -m "chore: bump version to X.Y.Z"
-
-# Create and push tag
-git tag vX.Y.Z
-git push origin main
-git push origin vX.Y.Z
-```
-
-## 📋 Conventional Commits
-
-The release system uses conventional commits to generate changelogs. Your commit messages should follow this format:
-
-```plain
-type(scope): description
-
-[optional body]
-
-[optional footer]
-```
-
-### Commit Types
-
-- `feat`: New features (triggers minor release)
-- `fix`: Bug fixes (triggers patch release)
-- `docs`: Documentation changes
-- `style`: Code style changes (formatting, etc.)
-- `refactor`: Code refactoring
-- `test`: Adding or updating tests
-- `chore`: Maintenance tasks
-
-### Breaking Changes
-
-To indicate a breaking change, use either:
-
-- `!:` in the commit message: `feat!: remove deprecated API`
-- `BREAKING CHANGE:` in the commit body:
-
-  ```plain
-  feat: new authentication system
-  
-  BREAKING CHANGE: Old auth methods are no longer supported
-  ```
-
-## 🔄 Workflow Comparison
-
-| Aspect | Automated Release | Manual Release |
-|--------|------------------|----------------|
-| **Trigger** | Push to main | Tag push or script |
-| **Release Type** | Auto-detected from commits | Manually specified |
-| **Effort** | Zero - fully automated | Manual intervention |
-| **Use Case** | Regular development flow | Hotfixes, special releases |
-
-## 🛠️ Configuration
-
-The release system is configured in:
-
-- `.github/workflows/auto-release.yml` - Automated release workflow
-- `.github/workflows/release.yml` - Manual release workflow (fallback)
-- `scripts/release.js` - Manual release automation script
-- `commitlint.config.js` - Conventional commits configuration
-- `package.json` - Version management and scripts
-
-## 🚨 Troubleshooting
-
-### Common Issues
-
-1. **No release created**: Check if commits follow conventional format
-2. **Wrong release type**: Ensure commit messages use correct prefixes
-3. **Tests failing**: Release won't proceed if tests fail
-4. **Permission denied**: Ensure GitHub token has write permissions
-
-### Debugging
-
-The automated workflow logs will show:
-
-- Last tag found
-- Commits since last tag
-- Determined release type
-- Calculated new version
-
-### Rollback
-
-If you need to rollback a release:
-
-1. Delete the tag locally: `git tag -d vX.Y.Z`
-2. Delete the tag on GitHub: `git push origin :refs/tags/vX.Y.Z`
-3. Revert the version in `package.json`
-4. Commit the revert: `git commit -m "chore: revert version to X.Y.Z"`
-5. Push the changes: `git push origin main`

package/RELEASE_SETUP.md

@@ -1,237 +0,0 @@
-# Automated Release System Setup
-
-## 🎯 Overview
-
-This project now has a **fully automated release system** that:
-
-1. **Automatically detects release types** from commit messages
-2. **Creates releases on every merge to main** (when there are changes)
-3. **Generates changelogs** from conventional commits
-4. **Publishes to npm** automatically
-5. **Provides manual fallback** for special cases
-
-## 🔄 How It Works
-
-### Automated Flow
-
-```plain
-Push to main → Tests run → Analyze commits → Determine release type → Create release
-```
-
-1. **Trigger**: Any push to the `main` branch (usually PR merges)
-2. **Testing**: Full test suite runs to ensure quality
-3. **Analysis**: System examines commits since last release
-4. **Decision**: Release type determined by commit messages:
-   - `major`: Breaking changes (`!:` or `BREAKING CHANGE:`)
-   - `minor`: New features (`feat:`)
-   - `patch`: Everything else (`fix:`, `docs:`, `chore:`, etc.)
-5. **Release**: If changes exist, creates GitHub release + npm publish
-
-### Manual Fallback
-
-```plain
-Create tag → Manual release workflow → Create release
-```
-
-For hotfixes or special releases, you can still use manual methods.
-
-## 📁 Workflow Files
-
-### `.github/workflows/auto-release.yml`
-
-- **Purpose**: Main automated release workflow
-- **Trigger**: Push to main branch
-- **Jobs**:
-  - `test`: Run tests
-  - `determine-release`: Analyze commits and decide release type
-  - `release`: Create release and publish
-
-### `.github/workflows/release.yml`
-
-- **Purpose**: Manual release fallback
-- **Trigger**: Push of version tags (`v*`)
-- **Use case**: Manual releases, hotfixes
-
-### `.github/workflows/test.yml`
-
-- **Purpose**: Quality assurance
-- **Trigger**: PRs and pushes to main
-- **Jobs**: Run tests and linting
-
-## 🎯 Release Type Detection
-
-The system analyzes commit messages since the last release:
-
-### Major Release (X.0.0)
-
-```bash
-git commit -m "feat!: remove deprecated API"
-git commit -m "feat: new system
-
-BREAKING CHANGE: Old methods no longer work"
-```
-
-### Minor Release (0.X.0)
-
-```bash
-git commit -m "feat: add OAuth2 support"
-git commit -m "feat(auth): implement JWT tokens"
-```
-
-### Patch Release (0.0.X)
-
-```bash
-git commit -m "fix: resolve memory leak"
-git commit -m "docs: update API docs"
-git commit -m "chore: update dependencies"
-```
-
-## 🛠️ Configuration Details
-
-### Commit Analysis Logic
-
-```bash
-# Check for breaking changes first
-if echo "$COMMITS" | grep -q "BREAKING CHANGE\|!:"; then
-  RELEASE_TYPE="major"
-# Then check for new features
-elif echo "$COMMITS" | grep -q "^feat"; then
-  RELEASE_TYPE="minor"
-# Default to patch
-else
-  RELEASE_TYPE="patch"
-fi
-```
-
-### Version Calculation
-
-Uses the `@pawel-up/semver` package for proper semantic versioning:
-
-```javascript
-import SemVer from '@pawel-up/semver/classes/semver.js';
-const ver = new SemVer(currentVersion);
-ver.inc(releaseType);
-return ver.format();
-```
-
-### Changelog Generation
-
-Uses `conventional-changelog` package with the `conventionalcommits` preset via a Node.js script (`scripts/generate-changelog.js`):
-
-```bash
-node scripts/generate-changelog.js
-```
-
-This approach uses the `conventional-changelog` library directly instead of the CLI tool, which resolves security vulnerabilities in the older `conventional-changelog-cli` package.
-
-## 🔧 Setup Requirements
-
-### GitHub Secrets
-
-- `GITHUB_TOKEN`: Automatically provided
-- `NPM_TOKEN`: Required for npm publishing
-
-### Dependencies
-
-- `conventional-changelog-cli`: For changelog generation
-- `@pawel-up/semver`: For version calculation
-- `@commitlint/config-conventional`: For commit validation
-
-### Permissions
-
-The workflows require these permissions:
-
-- `contents: write` - Create releases and tags
-- `issues: write` - Update issues
-- `pull-requests: write` - Update PRs
-
-## 🚀 Usage Examples
-
-### Normal Development Flow
-
-1. **Create feature branch**
-
-   ```bash
-   git checkout -b feature/new-auth
-   ```
-
-2. **Make changes with proper commits**
-
-   ```bash
-   git commit -m "feat: add OAuth2 authentication"
-   git commit -m "docs: update authentication docs"
-   ```
-
-3. **Create PR and merge to main**
-   - PR triggers test workflow
-   - Merge triggers auto-release workflow
-   - System creates minor release automatically
-
-### Hotfix Flow
-
-1. **Create hotfix branch**
-
-   ```bash
-   git checkout -b hotfix/critical-bug
-   ```
-
-2. **Fix and commit**
-
-   ```bash
-   git commit -m "fix: resolve critical memory leak"
-   ```
-
-3. **Merge to main**
-   - System creates patch release automatically
-
-### Manual Release (if needed)
-
-```bash
-# For immediate release
-npm run release:patch
-
-# Or create tag manually
-git tag v1.2.3
-git push origin v1.2.3
-```
-
-## 🔍 Monitoring and Debugging
-
-### Workflow Logs
-
-Check the GitHub Actions tab to see:
-
-- Which commits were analyzed
-- What release type was determined
-- Why a release was or wasn't created
-
-### Common Issues
-
-1. **No release created**: No new commits since last tag
-2. **Wrong release type**: Check commit message format
-3. **Tests failing**: Release won't proceed
-4. **Permission errors**: Check GitHub token permissions
-
-### Debugging Commands
-
-```bash
-# Check last tag
-git describe --tags --abbrev=0
-
-# See commits since last tag
-git log --pretty=format:"%s" $(git describe --tags --abbrev=0)..HEAD
-
-# Check conventional commit format
-npx commitlint --edit .git/COMMIT_EDITMSG
-```
-
-## 🎉 Benefits
-
-1. **Zero manual intervention** for regular releases
-2. **Consistent release process** with proper semantic versioning
-3. **Automatic changelog generation** from commit history
-4. **Quality gates** with automated testing
-5. **Flexible fallback** for special cases
-6. **Proper audit trail** with conventional commits
-
-This setup provides a modern, automated release system that follows industry best practices and reduces manual work while ensuring quality and consistency.