@opensas/xml-rest-adapter 0.2.0 → 0.2.1

package/dist/valid.js

@@ -23,7 +23,25 @@ function toPascalCase(str) {
     })
         .join('');
 }
-const getEndpoint = (app, objeto) => app.endpoints.find((ep) => ep.name === toPascalCase(objeto));
+// Match exacto primero. Si falla y el segmento tiene un separador `_` explícito, reintenta
+// case-insensitive: un `Endpoint.name` con un acrónimo en mayúsculas (`ActividadCIIU`,
+// `CategoriaCIIU`) nunca coincide con lo que arma `toPascalCase` a partir del segmento de URL
+// (`actividad_ciiu` → `ActividadCiiu`, con "Ciiu" no "CIIU") — ningún algoritmo genérico de
+// snake_case→PascalCase puede adivinar qué partes de un nombre compuesto son sigla.
+// convenios_web nunca tuvo este problema porque su comparación (`isValidObjeto`) ya era
+// case-insensitive — portado acá, pero acotado al caso con separador: sin `_` en el segmento
+// mantenemos el exacto a propósito (`tipodato`, sin límite de palabra explícito, sigue sin
+// matchear `TipoDato` — ver custom-url-casing.fixture.test.ts, cualquier coincidencia ahí sería
+// casualidad, no una reconstrucción real). Encontrado migrando `CctDigitalizacion` en
+// convenios_web (ver docs/todos/rest-baseline-pre-migracion.md).
+const getEndpoint = (app, objeto) => {
+    const pascal = toPascalCase(objeto);
+    const exact = app.endpoints.find((ep) => ep.name === pascal);
+    if (exact || !objeto.includes('_'))
+        return exact;
+    const normalized = pascal.toLowerCase();
+    return app.endpoints.find((ep) => ep.name.toLowerCase() === normalized);
+};
 export function validParams(app, path, withId = 'noId') {
     const [objetoRaw, idRaw] = path.split('/');
     if (!objetoRaw)

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@opensas/xml-rest-adapter",
-	"version": "0.2.0",
+	"version": "0.2.1",
 	"publishConfig": {
 		"access": "public"
 	},