@omnifyjp/omnify 5.8.2 → 5.8.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@omnifyjp/omnify",
-  "version": "5.8.2",
+  "version": "5.8.3",
   "description": "Schema-driven code generation for Laravel, TypeScript, and SQL",
   "license": "MIT",
   "repository": {
@@ -36,10 +36,10 @@
     "zod": "^3.24.0"
   },
   "optionalDependencies": {
-    "@omnifyjp/omnify-darwin-arm64": "5.8.2",
-    "@omnifyjp/omnify-darwin-x64": "5.8.2",
-    "@omnifyjp/omnify-linux-x64": "5.8.2",
-    "@omnifyjp/omnify-linux-arm64": "5.8.2",
-    "@omnifyjp/omnify-win32-x64": "5.8.2"
+    "@omnifyjp/omnify-darwin-arm64": "5.8.3",
+    "@omnifyjp/omnify-darwin-x64": "5.8.3",
+    "@omnifyjp/omnify-linux-x64": "5.8.3",
+    "@omnifyjp/omnify-linux-arm64": "5.8.3",
+    "@omnifyjp/omnify-win32-x64": "5.8.3"
   }
 }

package/ts-dist/php/translation-model-generator.js

@@ -64,6 +64,12 @@ function generateTranslationBaseModel(name, translatableFields, enforceLanguageF
     // Astrotomic's `translation_model_namespace` once globally instead
     // of per-model `$translationModel` overrides. Modular structure
     // already isolates per-Schema so this nesting only applies to legacy.
+    // Issue #98 v5.8.3: when `flatBase: true`, the model layer drops
+    // the `Base/` subfolder + `BaseModel` suffix everywhere else; the
+    // translation base must follow the same convention so naming
+    // stays consistent across layers (a class extending `Model` named
+    // `CategoryTranslationBaseModel` while siblings drop the suffix is
+    // the bug the reporter flagged).
     const baseNamespace = config.structure === 'modular'
         ? resolveModularBaseNamespace(config, name, 'Models', config.models.baseNamespace)
         : `${config.models.baseNamespace}\\Translation`;
@@ -93,6 +99,12 @@ function generateTranslationBaseModel(name, translatableFields, enforceLanguageF
     protected $casts = [
 ${castEntries.join('\n')}
     ];`;
+    // Issue #98 v5.8.3: honor flatBase. With flatBase=true the base
+    // class drops the `BaseModel` suffix and lives at the bare name,
+    // matching how every other Models-layer base behaves under flatBase.
+    // Modular structure ignores flatBase (per-Schema isolation already).
+    const flatBase = config.structure !== 'modular' && config.models.flatBase === true;
+    const baseClassName = flatBase ? `${modelName}Translation` : `${modelName}TranslationBaseModel`;
     const content = `<?php
 
 namespace ${baseNamespace};
@@ -107,9 +119,9 @@ namespace ${baseNamespace};
 use Illuminate\\Database\\Eloquent\\Model;
 
 /**
- * ${modelName}TranslationBaseModel
+ * ${baseClassName}
  */
-class ${modelName}TranslationBaseModel extends Model
+class ${baseClassName} extends Model
 {
     /**
      * The table associated with the model.
@@ -130,10 +142,11 @@ ${fillableLines}
 }
 `;
     // Issue #98 v5.8.2: legacy structure routes translation bases to
-    // `<modelsBasePath>/Translation/<Name>TranslationBaseModel.php`.
+    // `<modelsBasePath>/Translation/<Name>TranslationBaseModel.php`
+    // (or `${modelName}Translation.php` when flatBase drops the suffix).
     const filePath = config.structure === 'modular'
-        ? resolveModularBasePath(config, name, 'Models', `${modelName}TranslationBaseModel.php`, config.models.basePath)
-        : `${config.models.basePath}/Translation/${modelName}TranslationBaseModel.php`;
+        ? resolveModularBasePath(config, name, 'Models', `${baseClassName}.php`, config.models.basePath)
+        : `${config.models.basePath}/Translation/${baseClassName}.php`;
     return baseFile(filePath, content);
 }
 function generateTranslationUserModel(name, config) {
@@ -141,32 +154,51 @@ function generateTranslationUserModel(name, config) {
     // Issue #98 v5.8.2: editable translation stub also lives under
     // `Translation/` to mirror the base layout. Astrotomic finds it via
     // the project-set `translation_model_namespace`.
+    // Issue #98 v5.8.3 (Bug 1): when `userEditablePath` points elsewhere
+    // (e.g. canonical Laravel `app/Models/`), the namespace must match
+    // the FILE LOCATION, not the base namespace — otherwise PSR-4 fails
+    // at runtime. Use `userEditableNamespace` (resolved from the config
+    // override) instead of the base `models.namespace`.
     const modelNamespace = config.structure === 'modular'
         ? config.models.namespace
-        : `${config.models.namespace}\\Translation`;
+        : `${config.models.userEditableNamespace}\\Translation`;
     const baseNamespace = config.structure === 'modular'
         ? resolveModularBaseNamespace(config, name, 'Models', config.models.baseNamespace)
         : `${config.models.baseNamespace}\\Translation`;
+    // Issue #98 v5.8.3 (Bug 2): honor flatBase + alias on class-name
+    // collision. With flatBase the base class is also named
+    // `<Model>Translation` (no suffix); the editable stub then needs
+    // an alias to avoid a self-collision when extending. Mirrors the
+    // pattern used by resource / service / request user generators.
+    const flatBase = config.structure !== 'modular' && config.models.flatBase === true;
+    const baseClassName = flatBase ? `${modelName}Translation` : `${modelName}TranslationBaseModel`;
+    const editableClassName = `${modelName}Translation`;
+    const baseAlias = baseClassName === editableClassName
+        ? `${editableClassName}Base`
+        : baseClassName;
+    const baseImport = baseAlias === baseClassName
+        ? `use ${baseNamespace}\\${baseClassName};`
+        : `use ${baseNamespace}\\${baseClassName} as ${baseAlias};`;
     const content = `<?php
 
 namespace ${modelNamespace};
 
-use ${baseNamespace}\\${modelName}TranslationBaseModel;
+${baseImport}
 
 /**
- * ${modelName}Translation Model
+ * ${editableClassName} Model
  *
  * This file is generated once and can be customized.
  * Add your custom methods and logic here.
  */
-class ${modelName}Translation extends ${modelName}TranslationBaseModel
+class ${editableClassName} extends ${baseAlias}
 {
     // Add your custom methods here
 }
 `;
     // Editable file path mirrors the namespace nesting.
     const filePath = config.structure === 'modular'
-        ? `${config.models.path}/${modelName}Translation.php`
-        : `${config.models.userEditablePath}/Translation/${modelName}Translation.php`;
+        ? `${config.models.path}/${editableClassName}.php`
+        : `${config.models.userEditablePath}/Translation/${editableClassName}.php`;
     return userFile(filePath, content);
 }

package/ts-dist/php/types.js

@@ -184,10 +184,19 @@ nsFromPath) {
     const baseNamespace = flatBase ? namespace : `${namespace}\\${baseSubfolder}`;
     // User-editable: defaults to the same dir as base (legacy behavior),
     // overridable to e.g. canonical Laravel paths (`app/Models/`).
+    // Issue #98 v5.8.3: when only `userEditablePath` is overridden,
+    // derive the namespace from the editable PATH (not the base
+    // namespace) so the file's `namespace ...;` declaration matches
+    // its physical location and PSR-4 autoload doesn't break at
+    // runtime. Reporter hit this with `userEditablePath: app/Models`
+    // and the base path defaulting to `app/Omnify/Models/`: the
+    // editable stub claimed the base namespace and Laravel couldn't
+    // load it.
     const userEditablePath = override?.userEditablePath
         ? withRoot(rootPath, override.userEditablePath)
         : path;
-    const userEditableNamespace = override?.userEditableNamespace ?? namespace;
+    const userEditableNamespace = override?.userEditableNamespace
+        ?? (override?.userEditablePath ? nsFromPath(userEditablePath) : namespace);
     return { namespace, baseNamespace, path, basePath, userEditablePath, userEditableNamespace, flatBase };
 }
 /**