Qwik — Crear y publicar librería en NPM

Claves para poder crear nuestras librerías de Qwik y publicarlas en NPM con esta guía completa paso a paso

En este artículo, os explicaré todas las claves para poder crear nuestra propia librería Qwik, paso a paso, y distribuirla en NPM para que otras personas puedan utilizarla, al igual que nosotros utilizamos librerías externas en nuestros proyectos.

Para trabajar con este artículo os recomiendo que estudiéis los contenidos de los artículos anteriores, sobre todo el correspondiente a componentes ya que será lo que vamos a trabajar principalmente junto con los conceptos de desarrollo de una librería en Qwik.

Os recomiendo leer los artículos anteriores en orden y si practicáis, ¡¡mucho mejor!!.

Recordad, que si hay dudas, aun leyéndolo, podéis preguntarlo en los comentarios.

Todos los artículos publicados del curso los encontraréis en la siguiente lista que iré actualizando semanalmente y estableciendo el orden natural recomendado:

Anartz Mugika Ledo🤗

Qwik paso a paso desde 0 al detalle

View list

23 stories

Si queréis recibir notificaciones sobre este contenido y similares, os animo a que os suscribáis a mi lista de correo:

Get an email whenever Anartz Mugika Ledo🤗 publishes.

Solo habrá avisos con nuevos contenidos, es decir, nuevos artículos (1–3 máximo a la semana, generalmente 1).

El tutorial es compatible con todas las versiones de Qwik hasta el momento. Actualmente en el proyecto de librería se trabajará con la versión 1.1.5 en lo que respecta a la librería y esta será con la que desarrolle el código de lo que vamos a encontrar a continuación.

Se está trabajando para que la librería sea compatible con todas las versiones de Qwik ≥ 1.0.0, próximamente está listo

Apartados que vamos a ver en este artículo

Estos serán los temas que vamos a trabajar en este artículo, desde lo que es la introducción hasta publicar nuestro primer paquete Qwik.

• Introducción.
• Requisitos mínimos previos.
• Preparativos.
• Estructura del proyecto.
• Probando los elementos de la librería en app Qwik.
• Creando y consumiendo un nuevo componente.
• Compilación.
• Consideraciones después de desarrollar la biblioteca
• Cómo consumir el paquete generado para probarla localmente
• Publicar paquete en NPM.
• Consumir nuestro paquete NPM.
• Conclusión

Introducción

Qwik utilizará el modo de librería de Vite para crear librerías de componentes.

Para crear una librería de componentes para Qwik, debemos asegurarnos de seguir unas reglas específicas para que el optimizador de Qwik pueda reconocer nuestra librería como tal.

La forma más sencilla de crear una nueva biblioteca de componentes es utilizando la referencia oficial, donde se exponen los temas a tener en cuenta y los pasos a seguir, aunque bajo mi punto de vista creo que le falta información y hacerle algunos ajustes para mejorarlo.

Por este motivo, siguiendo un poco mi propia estructura, mis gustos personales y mi forma de organizar las cosas, he creado mi versión alternativa añadiendo algunas configuraciones que me gustan más (abierto a sugerencias de mejora)

Por supuesto, siempre respetando que el optimizador de Qwik pueda reconocer el proyecto como una librería de Qwik, si no, que sentido tendría hacerlo.

Requisitos mínimos previos

• Cuenta de NPM (os podéis registrar desde aquí)
• Conocimientos básicos de Qwik (con haber trabajado en las bases más que suficiente aunque si no tenéis conocimientos, os dejo mi curso GRATIS)
• Ganas de aprender y posteriormente experimentar con lo aprendido en implementaciones propias (HIPER RECOMENDADO)

Preparativos

Para continuar con el desarrollo de la librería paso a paso, tenemos que descargar el proyecto. Os proporciono dos opciones, seleccionar la que más os guste:

• Descargar el proyecto en formato zip.
• Crear un nuevo repositorio utilizando la plantilla.

Una vez que hayamos descargado el proyecto

• Seleccionar la versión Node: 16 o 18(importante).
• Instalar las dependencias del proyecto utilizando el comando npm install (o similares como yarn)

Con esto ya tenemos el primer paso completado, el de tener disponible el proyecto.

Lo abrimos en el editor de código (por ejemplo Visual Studio Code) o cualquiera que usemos para implementar el código.

Estructura del proyecto

Ahora vamos a analizar la estructura del proyecto y mencionaré las cosas que debemos tener en cuenta en lo que respecta al proyecto de la librería, para poder trabajar sabiendo qué estamos modificando y qué necesitamos para llegar al punto de publicar nuestra librería sin hacer las cosas a ciegas.

Es prácticamente la misma estructura que el proyecto que se crear a partir del generador aunque tiene algunas diferencias que facilitan más el trabajo.

Esta será la estructura:

├── README.md
├── package.json
├── src
│ ├── components
│ │     ├── counter
│ │     │     └── index.tsx
│ │     └── logo
│ │           └── index.tsx
│ ├── hooks
│ │     └── useCounter.tsx
│ ├── entry.dev.tsx
│ ├── entry.ssr.tsx
│ ├── index.ts
│ └── root.tsx
├── tsconfig.json
└── vite.config.ts

De estos archivos los más importantes en una librería en Qwik son los ficheros package.json y vite.config.ts configurados correctamente.

Ahora vemos estos ficheros junto con los otros con sus características y detalles a tener en cuenta.

package.json

Empezamos hablando del fichero package.json, que es el fichero que necesitamos para poder añadir y gestionar la información de nuestros proyectos de desarrollo de software en JavaScript y Node.js.

Se utiliza principalmente para gestionar las dependencias del proyecto, scripts de ejecución, metadatos y otra información relevante que se necesitará especificar.

En el caso de Qwik, tenemos que tener en cuenta la siguiente estructura, estos campos que se muestran a continuación son importantes y aunque algunos no sean obligatorios su uso, se recomiendan añadirlos.

El contenido del fichero del manifiesto del template que estamos usando para el desarrollo de una librería de Qwik es el siguiente:

{
  "name": "qwik-template-library",
  "version": "0.0.1",
  "description": "Create a reusable Qwik component library",
  "main": "./dist/index.qwik.cjs",
  "qwik": "./dist/index.qwik.mjs",
  "module": "./dist/index.qwik.mjs",
  "types": "./dist/types/index.d.ts",
  "exports": {
    ".": {
      "import": "./dist/index.qwik.mjs",
      "require": "./dist/index.qwik.cjs",
      "types": "./dist/types/index.d.ts"
    }
  },
  "files": [
    "dist",
    "!dist/types/root.d.ts",
    "!dist/types/entry.dev.d.ts",
    "!dist/types/entry.ssr.d.ts"
  ],
  "directories": {
    "lib": "dist"
  },
  "engines": {
    "node": ">=15.0.0"
  },
  "private": false,
  "type": "module",
  "scripts": {
    ...
  },
  "devDependencies": {
    ...
  }
}

Ahora haré hincapié en las propiedades más importantes y las restantes las menciono en conjunto con una breve explicación.

• qwik: Una propiedad super importante es la propiedad qwik, que será el punto de entrada para que el Optimizador de Qwik reconozca como una librería de Qwik. Hay que añadir la referencia con la extensión .qwik.mjs, de lo contrario el optimizador de Qwik NO LO RECONOCERÁ. Este fichero se genera con npm run build
• main: Punto de entrada de la librería. En este caso añadimos el fichero con la extensión .qwik.cjs que contiene el código compilado de Common JS. Este fichero se genera con npm run build
• types: Referencia para acceder a los types de nuestra librería. En este caso añadimos el fichero con la extensión .d.ts que contiene el código compilado con los tipos generado de nuestro desarrollo. Este fichero se genera con npm run build
• name: Nombre del paquete. Fundamental y es obligatorio. Debe de respetar la convención de nombres de paquetes teniendo en cuenta lo siguiente. Luego vemos este detalle cuando nos centremos en el punto de prepararlo para producción.
• exports: Referencias a los ficheros generados para poder consumir la librería.
• files: Ficheros que se añadirán al paquete final para publicarlo en NPM tanto haciendo npm pack (para pruebas locales) o el comando para mandarlo a producción, es decir, npm publish. Los ficheros que tienen ! por delante serán ficheros que se ignorarán al empaquetar la librería, no se ignoran al hacer npm run build
• type: Añadimos module, no cambiar esto.

Luego tendremos las siguiente propiedades como engines(versión de Node que se usará, en este caso mayor o igual que 15, recomendable hacerlo con 16 o 18), y devDependencies(dependencias que necesitamos para nuestro desarrollo) y scripts(Ejecutar las diferentes tareas como compilado).

Con esto, ya hemos analizado el fichero del manifiesto de nuestros proyectos, el package.json

vite.config.ts

En comparación con una configuración normal de Vite, las bibliotecas utilizarán el modo lib de Vite, lo cual nos obliga a que tengamos bien configurado el script build.lib, cosa que ya tenemos completado con esta plantilla.

Si necesitáis hacer algún cambio, os recomiendo que uséis el enlace proporcionado sobre como trabajar en el modo de librería en Vite.

El fichero de configuración en este caso será el siguiente:

import { defineConfig } from 'vite';
import { qwikVite } from '@builder.io/qwik/optimizer';
import dts from 'vite-plugin-dts';

export default defineConfig(() => {
  return {
    // 1.- Opciones de compilado
    build: {
      target: 'es2020',
      // 2.- Configuración para generar nuestra librería compilada con ficheros necsarios para Qwik
      lib: {
        entry: './src/index.ts',
        formats: ['es', 'cjs'],
        fileName: (format: string) => `index.qwik.${format === 'es' ? 'mjs' : 'cjs'}`,
      },
      // 3.- Directorio de salida, fijaros que concuerda con main, qwik,...del package.json
      outDir: './dist'
    },
    plugins: [qwikVite(), dts()],
  };
});

src

Directorio donde se añaden todos los componentes y elementos que van a implementarse en nuestra librería.

Es importante que tengamos el fichero index.ts dentro de el, ya que este fichero es el punto de entrada de nuestra librería, exportando todos los componentes y funciones que deseamos proporcionar a los que consumen la librería para facilitar su uso, simplemente teniendo que hacer referencia al nombre del paquete y no a nombre del paquete + el path relativo donde se encuentre ese elemento.

La estructura del directorio en este template es la siguiente:

...
├── src
│ ├── components
│ │     ├── counter
│ │     │     └── index.tsx
│ │     └── logo
│ │           └── index.tsx
│ ├── hooks
│ │     └── useCounter.tsx
│ ├── index.ts
...

Ahí podemos ir añadiendo todo lo que necesitemos, pero eso si, procurad ir añadiendo en el fichero index.ts todos los elementos que queramos compartir.

Ahora mismo, con la estructura que tenemos, el fichero src/index.ts tiene configurado de la siguiente forma:

export { Logo, type LogoProps } from './components/logo';
export { Counter } from './components/counter';
export { useCounter } from './hooks/useCounter';

Con esto, si ya tenemos por ejemplo que nuestro paquete se llama qwik-openweather-map para poder consumirlo en una aplicación que hemos instalado estas dependencias, podremos consumirlo de la siguiente forma:

import {Logo, Counter} from qwik-openweather-map;

Donde estaremos accediendo a los componentes <Logo /> y <Counter />, pudiendo acceder si quisiéramos al hook useCounter y a los props del componente<Logo />, que será LogoProps

tsconfig.json

El archivo tsconfig.json es un archivo de configuración que se utiliza en proyectos que están escritos en Typescript.

Nos proporciona opciones y ajustes para el compilador de TypeScript, permitiendo personalizar el comportamiento de compilación y configurar características específicas del proyecto.

Contiene información como la versión de TypeScript utilizada, los archivos fuente a incluir o excluir, la ruta de salida de los archivos compilados y otras configuraciones relacionadas con el proceso de compilación de TypeScript.

src/entry.dev.tsx, src/entry.ssr.tsx y src/root.tsx

Las librerías también son aplicaciones, a menor escala, pero lo son.

El inicio de la librería también será una aplicación independiente de Qwik (sin enrutamiento ni Qwik City) donde podréis encontrar los archivos src/entry.dev.tsx, src/entry.ssr.tsx y src/root.tsx.

No os preocupéis por ellos, no van a formar parte de la librería final, pero son útiles durante el desarrollo y las pruebas, para que podamos probar nuestras implementaciones en una aplicación de Qwik real.

Para ignorar estos ficheros, recordad lo visto en el package.json con files, cuyo apartado muestra los 3 ficheros que tienen por delante ! haciendo que se ignoren en la librería compilada. Se ha configurado para que esos ficheros no formen parte del resultado final, solo serán útiles en el desarrollo.

Una vez analizada la estructura principal de la librería, comenzamos ejecutando el comando para iniciar la aplicación real de Qwik donde se pueden ver como se consumen los dos componentes que contiene la librería actualmente.

Probando los elementos de la librería en app Qwik

Para iniciar el proyecto (estamos trabajando en la librería), debemos de ejecutar el siguiente comando:

npm start

Una vez que se compile y esté todo OK, se nos abre una nueva pestaña y debería de aparecer algo similar a lo siguiente:

Y todo esto se ha definido en el fichero src/root.tsx de la siguiente manera:

// 1 Importamos los componentes que estamos usando
import { Counter } from './components/counter';
import { Logo } from './components/logo';

// 2.- Consumimos los componentes Logo y Counter, como se puede ver
export default () => {
  return (
    <>
      <head>
        <meta charSet='utf-8' />
        <title>Qwik Library Template - By Anartz</title>
      </head>
      <body>
        <h2>Example components</h2>
        <h4>Created by: Anartz Mugika Ledo</h4>
        <h4><code>{`<Logo />`}</code> component</h4>
        <Logo
          url='https://qwik.builder.io/'
          alt='Qwik Logo'
          width={400}
          height={147}
          image='https://cdn.builder.io/api/v1/image/assets%2FYJIGb4i01jvw0SRdL5Bt%2F667ab6c2283d4c4d878fb9083aacc10f'
        />
        <h4><code>{`<Counter />`}</code> component with <code>{`useCounter`}</code> custom hook</h4>
        <Counter />
      </body>
    </>
  );
};

Cualquier cambio, para añadir nuevos componentes, lo haremos dentro de body

Creando y consumiendo nuevo componente

Ahora que ya hemos visto como está estructurado el directorio del código fuente de nuestra librería y como consume los componentes que contiene, vamos a crear un componente propio desde 0.

Si no sabéis como trabajar con componentes, os recomiendo este artículo que escribí hace un tiempo sobre los componentes

Creamos el directorio hello dentro de src/components y habiéndonos ubicado sobre el, añadimos el fichero index.tsx con el siguiente contenido:

import { component$ } from '@builder.io/qwik';

export const Hello = component$(() => {
  return <>Hola, estamos trabajando con la librerías en Qwik :)</>;
});

Y si lo añadimos en el fichero src/root.tsx:

// ...
// 1.- Importamos
import { Hello } from './components/hello'

export default () => {
  return (
    <>
      <head>
        <meta charSet='utf-8' />
        <title>Qwik Library Template - By Anartz</title>
      </head>
      <body>
        ...
        <br/><br/><br/>
        // 2.- Consumimos el componente
        <Hello />
      </body>
    </>
  );
};

Al guardar y recargarse la página inicial de la aplicación, se verá de la siguiente forma:

Con esto podemos decir que ya tenemos lo necesario, aunque no hemos terminado, debemos de hacer que sea visible desde el punto de entrada en src/index.tsx, por lo que vamos a añadirlo con lo siguiente:

export { Hello } from './components/hello';

Siendo el resultado en src/index.tsx

export { Logo, type LogoProps } from './components/logo';
export { Counter } from './components/counter';
export { useCounter } from './hooks/useCounter';
export { Hello } from './components/hello';

Con esto, ya hemos visto todo lo que es relacionado a consumir dentro del proyecto de la librería y crear un componente de una manera muy sencilla.

Pasamos al punto donde ya vamos a hacer que nuestro desarrollo esté disponible a todo el mundo, pudiendo ser con un paquete que se ejecutará en local o publicándolo en NPM.

Lo vamos a ver de las dos formas, ya que tanto hacerlo para trabajar en local o con NPM me parecen super interesantes.

Compilación

Para publicar nuestra librería, primero debemos compilarla en modo librería

Para hacer este proceso y crear la compilación debemos de ejecutar el script build

npm run build

Se ejecutarán varios scripts de manera consecutiva de manera ordenada

npm run build.types
npm run build.lib
npm run lint

Una vez que se completan los pasos, se consigue el resultado generado en el directorio dist, que con lo que tenemos hasta ahora debería de ser algo así:

...
├── dist
│ ├── types
│ |    │── entry.dev.d.ts
│ |    │── entry.ssr.d.ts
│ |    │── root.d.ts
│ |    │── index.d.ts
│ |    │── components
│ │    │      ├── counter
│ │    │      │     └── index.d.ts
| |    │      ├── logo
│ │    │      │     └── index.d.ts
| |    │      └── hello
│ │    │            └── index.d.ts
│ |    └── hooks
│ │         └── useCounter.d.ts
│ ├── index.qwik.cjs
│ ├── index.qwik.mjs
...

Y este es el contenido de nuestra librería compilada dentro de dist.

Cuando hagamos ejecutar las opciones de publicación tanto en local (npm pack) como en producción (npm publish) se ignorarán los ficheros correspondientes a:

• dist/types/entry.dev.d.ts
• dist/types/entry.ssr.d.ts
• dist/types/root.d.ts

Ahora vamos a pasar al apartado de producción generando el paquete para distribuirlo en local para ver que funciona todo correctamente.

Consideraciones después de desarrollar la biblioteca

Una vez que ya hemos probado nuestros componentes, hooks y otros elementos, es hora de pensar en enviarlo a producción.

Antes de subirlo directamente a NPM (o Github Packages), es interesante que podamos generar el paquete localmente y consumirlo instalándolo en otro proyecto que vamos a crear desde cero para acercarnos lo máximo posible a lo que se daría en una situación real respecto a consumir un paquete de NPM.

Crear la compilación de producción

La compilación de producción debería generar la versión de producción de nuestra librería de componentes en ./dist y las definiciones de tipo de TypeScript en ./dist/types

npm run build

Si queremos probarlo en un entorno de producción simulado, es decir, creando una nueva app independiente, debemos crear el archivo tgz localmente.

Esto sería prácticamente lo mismo que tratar de instalar un paquete desde cualquier repositorio como NPM, pero en este caso lo haremos con la referencia relativa del archivo con extensión tgz.

Crear nuestro paquete *.tgz

Para crear el paquete compilado con la extensión tgz, primero debemos asegurarnos de que la versión de nuestro paquete y su nombre sean los correctos, ya que hay unas reglas a cumplir.

Lista de reglas que debemos cumplir para validar el nombre paquete NPM:

• Longitud mayor que cero.
• Todos los caracteres deben estar en minúsculas, es decir, no se permiten nombres en mayúsculas o mayúsculas y minúsculas.
• Puede consistir en guiones.
• No debe contener caracteres que no sean seguros para URL (ya que el nombre termina siendo parte de una URL).
• No debe comenzar con .o _
• No debe contener espacios
• No debe contener ninguno de los siguientes caracteres: ~)('!*
• No puede ser el mismo que un módulo principal de ni un nombre reservado o incluido en la lista negra. Por ejemplo, los siguientes nombres no son válidos: http, stream, node_modules, favicon.ico
• Longitud máxima 214 caracteres
• A la hora de publicar en NPM, no debe de existir. Aunque cumplamos las demás características, si ya está cogido el nombre, debemos de cambiarlo por uno que no esté ocupado

Para gestionar las versiones, trabajamos con la convención de versionado semántico.

Dado un número de versión MAJOR.MINOR.PATCH, se incrementa:

- La versión MAJOR cuando se realizan cambios incompatibles en la API.
- La versión MINOR cuando se agrega funcionalidad de manera compatible hacia atrás.
- La versión PATCH cuando se realizan correcciones de errores compatibles hacia atrás.
Además, se pueden usar etiquetas adicionales para pre-lanzamientos y metadatos de compilación como extensiones del formato MAJOR.MINOR.PATCH.

Esto se gestionará para cada nueva versión (que se vaya a publicar en NPM o Github Packages), agregando el valor correspondiente según lo que se haya realizado, si se han realizado cambios menores o más relevantes.

Recuerda que siempre tiene que ser superior que la versión anterior.

Por ejemplo:

• De 1.0.0 a 1.0.1 (Válido)
• De 1.0.1 a 1.0.0 (Inválido, por estar asignando una versión inferior)

Si deseamos consumir la biblioteca creada, necesitamos generar el archivo *.tgz, el cual se generará con el siguiente formato: <nombre paquete>.<version-paquete>.tgz (nombre del paquete y versión definidos en el archivo package.json).

Si nuestro paquete tiene los siguientes datos en el archivo package.json:

• nombre: qwik-template-library
• versión: 1.0.0

Al ejecutar npm run pack, se generará un archivo llamado qwik-template-library-1.0.0.tgz.

Este script pack va a ejecutar las siguientes ordenes del script de manera consecutiva:

# 1.- Elimina el directorio
rm -rf dist && npm cache clean --force
# 2.- Compilar el código como en el paso anterior 
# generando index.qwik.mjs y index.cjs entre otros
npm run build
# 3.- Crear un fichero tgz con todo el contenido de 
# dist, ignorando los ficheros especificados en el package.json
npm pack

Si todo va bien, debería de aparecer el fichero en el apartado de ficheros y directorios de nuestro proyecto:

Ahora va a tocar consumir el paquete localmente desde otro proyecto independiente.

Cómo consumir el paquete generado para probarla localmente

Antes de consumir el paquete, creamos el nuevo proyecto de Qwik, en la recién salida versión 1.2.5 (06/07/2023)

npm create qwik@1.2.5

Una vez creado el nuevo proyecto, traemos a la raíz de este el fichero generado con los componentes de nuestra librería:

Con esto, vamos a facilitar su instalación.

Con esto lo instalaremos mediante la ruta relativa (también es posible la absoluta) del fichero qwik-template-library-1.0.0.tgz que contiene los ficheros de la librería que nos permitirá consumirla en la nueva aplicación.

Ejecutamos este comando, teniendo en cuenta que está en el propio proyecto nuevo:

npm i <RUTA del paquete tgz>

# si hemos colocado el archivo en el directorio 
# raíz de nuestro nuevo proyecto
npm i qwik-template-library-1.0.0.tgz

Si todo ha ido bien, deberíamos de tener algo de este estilo:

Una vez instalado el paquete de NPM, podemos probarlo, basándonos en lo añadido en el fichero src/root.tsx

Accedemos al fichero src/routes/index.tsx y dejamos el fichero de la siguiente forma:

// 1.- Importamos los componentes de nuestra librería personalizada
// haciendo referencia al paquete "qwik-library"
import { Counter , Hello, Logo } from 'qwik-template-library';

import { component$ } from "@builder.io/qwik";

// 2.- Añadimos los componentes como en src/root.tsx del proyecto de la librería
export default component$(() => {
  return (
    <>
      <h1>Testing with custom Qwik Library 👋</h1>
      <Logo
        url='https://qwik.builder.io/'
        alt='Qwik Logo'
        width={400}
        height={147}
        image='https://cdn.builder.io/api/v1/image/assets%2FYJIGb4i01jvw0SRdL5Bt%2F667ab6c2283d4c4d878fb9083aacc10f'
      />
      <h4><code>{`<Counter />`}</code> component with <code>{`useCounter`}</code> custom hook</h4>
      <Counter />
      <br/><br/><br/>
      <Hello />
    </>
  );
});

Al guardar, ejecutamos para iniciar el proyecto y debería de mostrarse lo siguiente:

Con esto, hemos comprobado que la librería es correcta y podemos ir con seguridad a publicarla en NPM.

Publicar el paquete

Para poder publicar el paquete, debemos de tener en cuenta algunos ajustes, como el nombre del paquete, el versionado semántico y que ese paquete, que aunque tenga un nombre válido, no exista.

Lo que corresponde al formato de nombre y el versionado ya se ha explicado.

Lo que respecta a comprobar si existe o no, lo podremos encontrar en el apartado “Aspectos a tener en cuenta a la hora de publicar un paquete en NPM” del artículo donde publicamos una librería de NestJS

Una vez comprobados esos aspectos, lo que tenemos que hacer para publicarlo es ejecutar el comando npm publish

El nombre del paquete (después de cambiarlo en el fichero package.json en la propiedad name) que voy a publicar se va a llamar qwik-example-lib, por lo que en el momento que se publique podremos encontrar toda su información en el siguiente enlace.

Obviamente, si usáis este nombre, como mi paquete va a estar publicado, no lo podréis publicar por estar ocupado por mi

Lo ejecutamos, y si no estamos logueados con nuestros credenciales de NPM, nos los pedirán. Introducir nombre y contraseña junto con el email que hemos registrado nuestra cuenta.

Si todo va bien, este sería el flujo de lo que debería ocurrir en nuestra librería:

Y accedemos a su página, para comprobar que si se ha publicado:

Si fuese la primera publicación os recomiendo que comprobéis si debéis actualizar los campos de package.json, como name, version, description, etc.

Tenemos que tener en cuenta que antes de cualquier publicación, hay que tener presente que debemos de versionar (siguiendo la convención del versionado semántico) modificando el campo version del package.json.

Ya tenemos la librería publicada, ¡¡este es el primer paso a grandes desarrollos!!

¿Nos falta algo para terminar? Aunque sea opcional, es recomendable consumir la librería instalando el paquete haciendo referencia a NPM.

Consumiendo nuestro paquete NPM

Volvemos al proyecto donde hemos instalado el fichero con extensión tgz donde teníamos el contenido de nuestra librería que hemos acabado de publicar.

Vamos al terminal y añadimos:

npm install qwik-example-lib

Una vez instalado el paquete, sustituimos en src/routes/index.tsx, lo siguiente:

import { Counter , Hello, Logo } from 'qwik-template-library';

Por lo siguiente:

import { Counter , Hello, Logo } from 'qwik-example-lib';

Ahora si ejecutamos el proyecto, debería de seguir funcionando de la misma forma, ya que no se han realizado cambios en los componentes.

El resultado es prácticamente el mismo.

Con esto, se puede dar por finalizado este artículo.

Conclusión

Llegados a este punto sabemos el proceso detallado para crear librerías en Qwik y como publicarlas.

Lo que nos faltaría es darle más mimo al apartado de las instrucciones que se redactan en el README.md para que cualquier persona que consuma nuestra librería pueda hacerlo sin problemas y detalles como añadir un fichero de licencia, pero este no es el objetivo en este punto.

En lo demás, os he enseñado todos los trucos para poder desarrollar una librería y como hacer el proceso de pruebas, paso a paso, antes de publicarla en producción.

Código de lo desarrollado:

qwik-library-template/ at feature/example-article-medium · Qwik-Spanish/qwik-library-template

Librería publicada en NPM:

qwik-example-lib

Presencia en redes sociales

Podéis encontrarme en las siguientes redes.

• Twitter.
• Github
• Youtube