module.land

Qué era

En mayo de 2020 salió Deno 1.0. No tenía package.json ni registro central: los módulos se importaban por URL. module.land intentaba ser “como npm, pero bien hecho para Deno”. Lo montamos entre pagoru y yo.

Iniciabas sesión con GitHub, elegías un repositorio y ya era un módulo. Cada release nueva en GitHub era automáticamente una versión nueva en module.land, sin publicar nada a mano. También se podían compartir módulos privados.

La CLI

Es la parte en la que más me centré yo. Se instalaba con Deno y se llamaba land:

• land add moduleland/deno-lib@1.0.0 añadía la dependencia a un land.json con un alias corto, para importar moduleland/deno-lib@1.0.0/main.ts en vez de la URL completa.
• land update moduleland/deno-lib@2.0.0 actualizaba la versión y reescribía los imports de todo el proyecto. Sin versión, se quedaba con la última de la rama principal.
• land run main.ts ejecutaba el proyecto con los alias ya resueltos, aceptando los mismos flags que Deno.

Cómo estaba hecho

• Web en React con Redux, con la ficha de cada módulo y su README.
• API en Node.js con TypeScript y MongoDB, conectada a la API de GitHub para leer repositorios y releases.
• CLI en Deno, empaquetada con deno bundle e instalada con deno install.

Cómo acabó

Llegamos a tener algunos usuarios, y a la gente que lo probaba le gustaba la idea. A quien no le gustó fue al equipo de Deno: decían que un registro así iba en contra de lo que buscaban, que era importar módulos por URL sin intermediarios.

Lo archivamos a finales de mayo de 2020. Unos años después, el propio equipo de Deno lanzó JSR, su registro de paquetes con versiones y alias. Ejem, ejem.