> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-es/scenes-sdk7/libraries/create-libraries.md).

# Crear una librería

Crea tus propias librerías de Decentraland para compartirlas con otros

Las Libraries son una excelente manera de compartir soluciones a problemas comunes. Los desafíos complejos pueden abordarse una vez, encapsular las soluciones en una library y, cada vez que aparezcan, solo tendrás que escribir una línea de código. Al compartir libraries con la comunidad, podemos hacer que la productividad de todos los creadores crezca exponencialmente.

Actualmente, estas libraries en el [página de ejemplos](https://studios.decentraland.org/resources?sdk_version=SDK7\&resource_type=Library) están disponibles para que todos las usen. Te animamos a crear y compartir también las tuyas.

Siguiendo los pasos detallados aquí, puedes evitar la mayor parte de la complejidad que conlleva crear una library compatible con escenas de Decentraland y fácil de compartir con otros.

## Crear una library

> **📔 Nota**: Asegúrate de estar usando la versión 20 de Node o una más reciente antes de compilar tu library.

Para crear tu propia library y compartirla a través de NPM, haz lo siguiente:

1. Crea una carpeta nueva vacía y abre allí una nueva ventana de Visual Studio Code.
2. Selecciona la pestaña de Decentraland en la barra lateral del margen izquierdo de Visual Studio Code
3. expande **Crear proyecto**, luego selecciona **Library**

   Esto creará todos los archivos y dependencias predeterminados para una library de Decentraland.
4. Configura un nombre único `name` en `archivo package.json`. Este es el nombre que se usará al publicar en NPM; asegúrate de que no exista ya otro proyecto que use ese nombre en npm. Completa también la descripción y cualquier etiqueta para ayudar a otros a encontrar tu library.
5. Crea un nuevo *público* repositorio de GitHub para tu proyecto.

   El proyecto está configurado para usar github actions para publicar una nueva versión del paquete en cada push a `main`.

   En el `archivo package.json` archivo, asegúrate de que en `el repositorio` apuntes la `url` campo a la URL de tu repo. De ese modo, será fácil de encontrar para los usuarios que naveguen por [npmjs.com](https://www.npmjs.com).
6. Obtén un token de NPM:
   1. Crea una cuenta o inicia sesión en <https://www.npmjs.com/>.
   2. Ve a **Account > Access Tokens > Generate new Token** Crea un nuevo token, asígnale **Publicar** permisos.

      El mensaje de éxito incluye una cadena para el token recién generado. Copia esta cadena y guárdala en un lugar seguro.
7. En tu repositorio de GitHub, ve a **Settings > Secrets > Actions**, luego haz clic en **New Repository Secret**.

   Nombra tu secreto **NPM\_TOKEN**, y pega como valor la cadena del token de NPM.
8. Envía un cambio (cualquier cambio) a la rama main de tu repo de GitHub y el paquete se publicará.

   Eso es todo, ahora cualquiera puede instalar el paquete usando `npm i <package-name>`¡Ya puedes encontrar tu library si la buscas por nombre en [npmjs.com](https://www.npmjs.com).
9. Completa el `/src` folder de tu proyecto con toda la funcionalidad que quieras exponer y envía los cambios a GitHub.

## Desarrolla

Añade cualquier función, Component, etc. que quieras exponer en el `index.ts` archivo de la library, así serán fáciles de importar.

Por ejemplo, si añades un `RotatorComponent` componente en `index.ts`, entonces puedes importar este component en una scene escribiendo lo siguiente.:

`import { RotatorComponent } from 'my-library'`

Prueba tu library usándola en una nueva scene de Decentraland mientras la desarrollas. Instala tu paquete npm en una scene ejecutando `npm i <package-name>`. Luego crea una scene que sirva para probar la funcionalidad de la library. Intenta cubrir diferentes casos de prueba con tu scene, para asegurarte de que tu library funciona como esperas en cada caso.

### Iteraciones rápidas

Si necesitas hacer pequeños ajustes continuamente a tu library y probarlos, puede resultar agotador tener que hacer commit de los cambios y luego esperar a que se complete la publicación en npm antes de poder probar la nueva versión en una scene. Por suerte, existe una alternativa mucho más rápida para ejecutar pruebas con tu library.

En un **proyecto de scene de prueba**:

1. Añade este script a la `lista de scripts` en package.json: `"link-sdk": "cd node_modules/@dcl/sdk && npm link && cd ../js-runtime && npm link"`
2. Ejecuta `npm install`
3. Ejecuta `npm install YOUR_LIBRARY_PATH`, por ejemplo, `npm install /User/projects/dcl-sdk7-library-test`
4. Ejecuta `npm run link-sdk`

En el **proyecto de library**:

1. Ejecuta `npm install`
2. Ejecuta `npm run build`
3. Ejecuta: `npm link @dcl/sdk @dcl/js-runtime`

> **❗Advertencia**: El orden de estos pasos es importante. Puede que no funcione en otro orden.

Esto mantendrá tu scene sincronizada con la versión de la library que está directamente en tu unidad local. Para cualquier cambio en la library que quieras probar, solo ejecuta `npm run build` en la carpeta de la library; no es necesario publicar los cambios en GitHub ni en NPM.

> **💡 Consejo**: Para verificar que el enlace fue exitoso, ejecuta `npm ls --link`. Deberías ver el nombre de la library apuntando a la carpeta en tus archivos locales.

Si haces cambios en la library, debes ejecutar `npm run build` para actualizarlos. Para evitar tener que hacerlo cada vez:

1. Añade el script "start": "tsc -p tsconfig.json --watch" a la
2. Ejecuta `npm start` en la library

Cuando termines de probar, recuerda desvincular la library.

1. En la carpeta de la scene ejecuta `npm install <library name>`
2. Luego, en la library, ejecuta `rm -rf node_modules && npm install`

## Versionado

Las versiones de tu library se publican automáticamente en `npm` con un `@latest` y una `@next` etiqueta.

El `@next` La etiqueta siempre apunta al último commit en la `main` rama. Esta versión puede ser inestable, ya que es posible que los últimos cambios no se hayan probado. Los usuarios de tu library pueden instalarla (bajo su propia responsabilidad) haciendo `npm i <library name>@next`.

El `@latest` La etiqueta apunta a la última versión estable de la library. Esto es lo que los usuarios de tu library deberían instalar normalmente. Es la versión que npm obtiene cuando hacen `npm i <library name>`.

Para hacer que la `@latest` etiqueta apunte a tus últimos commits, tendrás que hacer una **publicación** de tu library en GitHub.

1. Abre la página de GitHub de tu proyecto. Abre el **Releases** enlace, en el margen derecho de la página.
2. expande **Borrador de nueva publicación**.
3. On **Elige una etiqueta** escribe un nombre para tu nueva versión, por ejemplo "1.1.0". Escribe también un nombre en **Título de la publicación**. Este suele ser el mismo nombre, "1.1.0".

   > Importante: La etiqueta debe ser un número, sin letras ni símbolos adicionales. El número debe ser mayor que el de las publicaciones anteriores.
4. Describe tu publicación para que los usuarios sepan qué hay de nuevo.

   > Consejo: Haz clic en el botón **Generar notas de la publicación automáticamente** para imprimir todos los commits desde la última publicación.
5. Pulsa **Publicar versión**. Esta acción desencadena una nueva publicación automática en npm con la `@latest` etiqueta. Los usuarios de tu library ahora descargarán esta versión.

## Notas sobre usabilidad

Intenta por todos los medios que tu library sea fácil de usar para otros creadores. Nuestras suposiciones siempre ayudan a dar forma a las herramientas que hacemos. A menudo estas suposiciones nos parecen obvias, pero otros con otro contexto pueden tener suposiciones completamente distintas.

* Elige cuidadosamente los nombres de todo en tu library, incluidas las funciones, los componentes y los parámetros. Es mejor tener un nombre largo que sea autoexplicativo que uno corto que sea un misterio total.
* Piensa ampliamente en los distintos casos de uso posibles para tu library. Quizá alguien use tu library en un smart wearable, quizá alguien necesite encender o apagar tu system en ciertos momentos, quizá alguien necesite añadir varias instancias de tu system en la misma scene. No todo el mundo se enfrentará a los mismos desafíos que tú.
* Dicho esto, no necesitas admitir todos los casos de uso posibles. De hecho, siempre hay compensaciones que hacer entre flexibilidad y simplicidad de uso; crear buenas herramientas consiste precisamente en encontrar el equilibrio adecuado. Sé estratégico acerca de dónde trazas la línea respecto a lo que decidiste no admitir. Sin embargo, es importante documentar claramente las limitaciones con las que te quedaste.
* Esto nos lleva a la Documentación. Documenta tu library claramente, con ejemplos, descripciones de lo que hace cada parámetro, comentarios sobre qué escenarios no funcionarían y qué suposiciones estás haciendo sobre el contexto en el que se usa. El archivo README.md de la library suele ser el mejor lugar para exponer este contenido.
* Otra gran herramienta es añadir comentarios de metadatos directamente en tu código. Estos comentarios se muestran en el IDE (como VS Studio Code) mientras los usuarios de tu library escriben. Puedes describir para qué sirve cada función/Component, qué espera recibir cada parámetro y qué devuelve una función. Gracias a esto, los usuarios de tu library no necesitan alternar entre el código y la docs; ¡todo está allí en un solo lugar! Por ejemplo, mira esta función de la `@dcl/ecs-scene-utils` library:

  ```ts
  /**
   * Limita un valor para que no exceda un mínimo ni un máximo.
   *
   * @param value - número de entrada
   * @param min - Valor mínimo de salida.
   * @param max - Valor máximo de salida.
   * @returns El valor asignado resultante entre el min y el max
   * @public
   */
  export function clamp(value: number, min: number, max: number) {
  	let result = value

  	if (value > max) {
  		result = max
  	} else if (value < min) {
  		result = min
  	}
  	return result
  }
  ```

  Los usuarios de esta library ven estas sugerencias mostrarse mientras escriben la `clamp()` función:
* Declara siempre los types. No dejes que la gente adivine qué estructura de objeto tendrá que consumir.
* Mantén tu library ligera y centrada en una sola funcionalidad. Cuando se compila una scene de Decentraland, todo el código de todas sus libraries se empaqueta con ella, incluso el código que nunca llama la scene. Por esta razón, es mejor evitar crear libraries grandes y voluminosas. Es mejor tener libraries ligeras que permitan a los creadores usar solo lo que realmente necesitan.
* Mantén un ojo en el repo de tu library; puede que la gente haga pull requests o reporte incidencias.
* Incluye la información de licencias en tu repo; así los demás sabrán si son libres de usar tu library. La library predeterminada incluye una licencia Apache 2 abierta; si quieres, siéntete libre de cambiarla.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/creator/content-creator-es/scenes-sdk7/libraries/create-libraries.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.