@codecraftkit/comet

Cliente del backend Meteor sobre DDP, envuelto en asteroid.

Estado: legacy. Los consumidores de este monorepo ya lo marcan como tal — useProfileSelect lo documenta como "solo modo legacy, DEPRECADO" y useCallComet/useTypeAHead avisan por consola. Si estás empezando algo nuevo, andá por GraphQL (@codecraftkit/use-gql-request). La 3.0.0 existe para que lo que todavía depende de comet no arrastre 5.8 MB de dependencias muertas ni una conexión sin cifrar.

Instalación

bun add @codecraftkit/comet

Peer dependency: cookies-next >= 4.0.0.

Uso

import CometApi from '@codecraftkit/comet'

const comet = CometApi({
  host: 'api.midominio.com',
  ssl: true,
  tokenKey: 'mi_app__token'
})

const res = await comet.call('user.list', { page: 1 })

Opciones

| Opción | Default | Qué hace | | --- | --- | --- | | host | 'localhost:3000' | Host del backend, sin protocolo. | | ssl | false | true o 'true' usan wss://. Cualquier otra cosa, ws://. Ver abajo. | | tokenKey | 'token' | Nombre de la cookie de la que sale el token. | | instance | '0' | Identificador de instancia. | | log | true | Logs por consola. | | logPrefix | 'app ->' | Prefijo de cada log. |

ssl en dev y en prod

El flag es configurable y el default sigue siendo ws://: en dev no hace falta tocar nada.

CometApi({
  host: process.env.NEXT_PUBLIC_METEOR_HOST,
  ssl: process.env.NEXT_PUBLIC_METEOR_SSL   // 'true' en prod, ausente en dev
})

Por eso se mantiene el soporte del string: cuando el flag sale de un .env, todo es string.

| Valor | Endpoint | | --- | --- | | ausente, false, 'false', '' | ws:// | | true, 'true' | wss:// | | 1, '1', 'TRUE', 'yes' | ws:// + aviso |

El aviso de conexión sin cifrar

Solo true y 'true' activan TLS. No se aceptan 1 ni 'yes' a propósito: adivinar qué strings significan "sí" es como se construyen estos bugs. En vez de eso, comet avisa una vez por proceso cuando la conexión sale en claro contra un host que sí está en internet:

[@codecraftkit/comet] Conectando a api.midominio.com por ws:// SIN CIFRAR.
Solo `ssl: true` o `ssl: "true"` activan wss(): revisa el valor que estas pasando.
Si es a proposito, pasa `ssl: false` y este aviso no sale.

En dev nunca sale. Se consideran fuera de internet: loopback (localhost, 127.0.0.1, 0.0.0.0, ::1), los TLD reservados por la RFC 6761 (.localhost, .test, .invalid, .example) y por mDNS (.local), y los rangos privados de la RFC 1918 (10.x, 192.168.x, 172.16-31.x).

ssl: false explícito lo silencia. Apagarlo a propósito es una decisión; olvidárselo no lo es, y solo lo segundo merece un aviso.

No lo silencia log: false. Ese flag apaga el ruido de debug; esto pasa una vez y dice que las credenciales viajan en claro.

call(method, data)

Llama un método del backend. Agrega el token como extraData sobre una copia de data: el objeto que pasás no se toca.

Un error del backend no lanza: vuelve como { success: false, message, _err }. Es el comportamiento de siempre y se mantiene.

El tercer parámetro se acepta y se ignora. En la 2.x se hacía config = config || {} y no se leía nunca más. useCometRequest se lo pasa en cada request y se descarta hace años. Queda documentado en vez de eliminado, porque sacarlo esconde que los llamadores lo mandan e inventarle una semántica ahora cambiaría en silencio lo que hace. asteroid.call() no recibe ninguna config: si alguna vez tiene que hacer algo, es una decisión aparte.

Migrar desde la 2.x

ssl ahora acepta booleanos — revisá esto primero

La 2.x hacía ssl === 'true', comparando contra el string. Si venías pasando ssl: true (booleano), estabas conectando por ws:// sin cifrar y sin ningún aviso.

CometApi({ host: 'api.test', ssl: true })   // 2.x -> ws://   3.0 -> wss://
CometApi({ host: 'api.test', ssl: 'true' }) // 2.x -> wss://  3.0 -> wss:// (igual)

Si dependías del comportamiento viejo, tu tráfico no estaba cifrado. No hay nada que migrar: hay que verificar que el backend acepte wss://.

El constructor ahora lanza

Antes, si asteroid fallaba al construirse, el catch hacía return error. En JavaScript devolver un objeto desde un constructor reemplaza la instancia, así que CometApi(...) devolvía un Error sin .call. El síntoma aparecía después y en otro archivo, como cometApi.call is not a function.

Ahora la excepción sale hacia arriba con el endpoint en el mensaje. Si envolvías la construcción esperando un valor de retorno, pasá a try/catch.

tokenKey por opción en vez de NEXT_PUBLIC_TOKEN_KEY

config.tokenKey ya existía en la 2.x: el constructor lo aceptaba y lo guardaba, y después _getExtraData leía process.env.NEXT_PUBLIC_TOKEN_KEY e ignoraba el campo. La opción estaba y no hacía nada.

Precedencia en la 3.0:

1. tokenKey de las opciones
2. process.env.NEXT_PUBLIC_TOKEN_KEY — deprecado, avisa una vez y se saca en la 4.0
3. 'token'

Leer process.env.NEXT_PUBLIC_* obliga a quien consume a usar un bundler que lo reemplace en tiempo de build. Next lo hace; Storybook, Vite, un test o un server propio no. Es el mismo motivo por el que se cambió [email protected].

call() ya no muta el objeto que le pasás

Antes hacía data.extraData = ... sobre el objeto recibido. Si reutilizabas ese objeto, te quedaba con un campo que nunca pusiste — y con el token adentro al serializarlo.

Fuera moment y crypto-js

• crypto-js (620 KB) estaba importado y nunca usado. Se fue entero.
• moment (5.2 MB) sostenía una sola llamada: el hh:mm:ss A del prefijo del log. Lo hace toLocaleTimeString sin dependencias, con salida idéntica.

Si tu app usa moment por su cuenta, seguí declarándolo: comet ya no lo pide.

Opciones que se fueron

loginMethod, resumeMethod y logoutMethod se aceptaban y se guardaban, pero no se leían en ningún lado: pertenecían a un flujo de login que nunca se implementó (_logged y _token también estaban muertos). Pasarlas nunca hizo nada, así que sacarlas no cambia el comportamiento.

Licencia

MIT © CodeCraft