
Cuando desarrollamos PWA's (<a href="https://web.dev/progressive-web-apps/" target="_blank" rel="noreferrer noopener">Progressive Web Apps</a>), necesitamos comprobar el funcionamiento de nuestra aplicación utilizando los service workers en modo offline, y para ello es necesario simular un servidor con un certificado SSL válido. El certificado SSL es un documento digital que nos permite tener una sesión del navegador encriptada, por lo que podremos acceder mediante el protocolo HTTPS (Hypertext Transfer Protocol Secure).

Para conseguir tener ambos requisitos, un servidor y un certificado, necesitaremos utilizar dos librerías.

Primero utilizaremos <a href="https://github.com/FiloSottile/mkcert" target="_blank" rel="noreferrer noopener">mkcert</a>, que tal como ellos la definen, es una herramienta sencilla para crear certificados de desarrollo de confianza local, y que no requiere configuración.

Vamos al <a href="https://github.com/FiloSottile/mkcert#installation" target="_blank" rel="noreferrer noopener">apartado de instalación de la herramienta</a> y la instalamos según nuestra necesidad. Y una vez tenemos instalada la librería, tenemos que ejecutar los siguientes comandos:

```sh
# La siguiente línea nos instala los certificados locales en el sistema
mkcert -install
```

Deberíamos ver un resultado como el siguiente:

<img class="contain-image" src="/images/posts/como-obtener-ssl-localhost/resultado-mkcert-install.png" alt="Resultado de la instalación de mkcert" />

```sh
# Accedemos a nuestro proyecto
cd ruta/de/nuestro/proyecto

# Esta línea genera los certificados para los dominios que añadamos
# En este caso creamos un certificado para 127.0.0.1 y modificamos
# los nombres como cert.pem y key.pem
mkcert -cert-file cert.pem -key-file key.pem 127.0.0.1
```

Deberíamos ver un resultado como el siguiente:

<img class="contain-image" src="/images/posts/como-obtener-ssl-localhost/resultado-certificados.png" alt="Resultado de los certificados" />

Con estos comandos obtenemos nuestros archivos certificados que utilizaremos en nuestro servidor. Vamos a simular que dentro de este directorio tenemos desarrollada una PWA en alguna librería Javascript, como puede ser Vue o React, y que este proyecto se compila para producción en una carpeta llamada `dist` con un script llamado `build`. Y ya que los service workers funcionan dentro de un entorno de producción, primero vamos a necesitar ejecutar esta compilación. Y posteriormente, utilizaremos la librería <a href="https://www.npmjs.com/package/http-server" target="_blank" rel="noreferrer noopener">http-server</a> para generar nuestro servidor HTTP y lo ejecutaremos utilizando <a href="https://www.npmjs.com/package/npx" target="_blank" rel="noreferrer noopener">npx</a>.

```sh
# Compilamos nuestro proyecto para un entorno de producción
npm run build

# Ejecutamos nuetro servidor y le pasamos los siguientes parámetros:
# 1. la carpeta donde se compila nuestro proyecto (dist)
# 2. -S que nos habilita el protocolo seguro (SSL)
# 3. -C cert.pem para indicarle dónde se encuentra nuestro certificado,
#    previamente generado con mkcert.
npx http-server dist -S -C cert.pem
```

Deberíamos ver un resultado como el siguiente, y en este caso, podremos acceder a nuestro proyecto a través de la url que nos indica (`https://127.0.0.1:8080`):

<img class="contain-image" src="/images/posts/como-obtener-ssl-localhost/resultado-http-server.png" alt="Resultado de nuestro servidor" />


Cuando desarrollamos PWA's, necesitamos comprobar el funcionamiento de nuestra aplicación utilizando los service workers en modo offline, y para ello es necesario simular un servidor con un certificado SSL válido.

Cómo obtener un certificado SSL en localhost



Dentro de uno de nuestros proyectos tuvimos alertas sobre algunas vulnerabilidades de algunas dependencias, una versión de `minimist` en concreto.

Por lo general, suele ser sencillo. Actualizando nuestras dependencias, manualmente o gracias a la ayuda de paquetes como [npm-check-updates](https://www.npmjs.com/package/npm-check-updates). Pero hay situaciones un poco más complejas porque no sabemos qué dependencia esta utilizando ese paquete ni cómo actualizar dicha versión, especialmente si no lo siguen manteniendo. Vamos a ver varias maneras de encontrarlo.

Para listar las dependencias de nuestro proyecto podemos utilizar el siguiente comando, que nos dará un listado similar a la imagen siguiente:

```
yarn list
```

![Yarn list](/images/posts/auditoria-de-dependencias-con-yarn/yarn-list.png)

Existen [otras opciones interesantes de yarn list](https://classic.yarnpkg.com/en/docs/cli/list/) para filtrar el resultado.

Pero este listado suele ser bastante extenso, dependiendo de la cantidad de dependencias que tenga nuestro proyecto.

Para encontrar qué dependencia está utilizando el paquete que estamos buscando lo podemos hacer de manera más fácil y directa. En este ejemplo, utilizaremos `optimist` que es un paquete _deprecated_ que lo importaba otra dependencia y que nos estaba generando problemas de vulnerabilidad.

Si ejecutamos el siguiente comando, obtendremos la información necesaria para saber qué dependencias utilizan este paquete.

```
yarn why optimist
```

![Yarn why](/images/posts/auditoria-de-dependencias-con-yarn/yarn-why.png)

Podéis ver [otras opciones interesantes de yarn why](https://classic.yarnpkg.com/en/docs/cli/why/) que nos ayudan a refinar la búsqueda.

Gracias al resultado de este comando pudimos ver que se estaba importando en nuestra dependencia `karma`.

Con estos comandos trazamos de dónde provenía el error, pero podemos utilizar el siguiente comando para hacer una auditoría de nuestras dependencias para encontrar las vulnerabilidades de una manera más detallada y poder tomar acciones para solucionarlo.

```
yarn audit
```

![Yarn audit](/images/posts/auditoria-de-dependencias-con-yarn/yarn-audit.png)

Si queréis [saber más sobre yarn audit](https://classic.yarnpkg.com/en/docs/cli/audit/) podéis acceder a la información que nos ofrecen en su página.

Una vez conocemos cómo solucionar nuestro problema, existe una opción que podemos utilizar en nuestro `package.json` para actualizar estas dependencias.

```json
{
    ...

    "resolutions": {
      "minimist": "1.2.5"
    },

    ...
}
```

Con esto, solo quedará eliminar la carpeta `node_modules` y el archivo `yarn.lock` y volver a ejecutar:

```
yarn install
```


Auditoría de dependencias con Yarn


El mensaje de error `Constant FORCE_SSL_ADMIN already defined` ocurre cuando tienes la variable `FORCE_SSL_ADMIN` definida varias veces o no se encuentra en el lugar correcto.

Revisa si has activado el SSL en tu sitio WordPress. Es decir, que hayas añadido las siguientes líneas a tu fichero `wp-config.php`:

```php
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);
```

Si es así, es probable que el error sea debido a que las variables `FORCE_SSL_ADMIN` **no estén** definidas por encima de esta línea de comentarios que marca el final de la configuración personalizada del archivo de configuración de Wordpress. Tu código debería quedar de la siguiente manera:

```php
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

/* That's all, stop editing! Happy blogging. */
// 👆🏽 debe quedar antes de esta línea
```


Constant FORCE_SSL_ADMIN already defined


La **tipografía fluida** (_Fluid font type_) no es tan difícil de alcanzar, incluida la compatibilidad entre los distintos navegadores. ¿IE9 también?... Sí amigos, también en nuestro "querido" y olvidado compañero. Pero antes de hablar de la **tipografía fluida** vale la pena diferenciarla del significado de *Responsive Typography*. _Responsive Typography_, como su propio nombre indica, es una tipografía que responde al tamaño de la pantalla, o como lo conocemos en CSS, a los _breakpoints_ (media queries).

```css
html {
    font-size: 16px;
}

.title {
    font-size: 1.5rem;
}

@media screen and (min-width: 640px) {
    .title {
        font-size: 2.5rem;
    }
}

@media screen and (min-width: 960px) {
    .title {
        font-size: 4rem;
    }
}

@media screen and (min-width: 1200px) {
    .title {
        font-size: 6rem;
    }
}
```

Como podéis imaginar, la fuente de nuestro increíble componente _**.Foo**_ tendrá los siguientes tamaños (_mobile first_):

-   `1.5rem` que se traduce a `24px` (según nuestro tamaño de fuente raíz: `16px`)
-   `2.5rem` (`40px`) a partir de `640px`
-   `4rem` (`64px`) a partir de `960px`
-   `6rem` (`96px`) a partir de `1200px`

Lo que estamos haciendo es que el tamaño de fuente responda al tamaño de la ventana que nosotros marcamos, pero lo hace con un salto de tamaño de un punto a otro, sin pasar por los tamaños intermedios, es decir, no hay un paso de `1.5rem` a `2.5rem`. Y esto es en lo que se diferencia una **tipografía fluida**. ¿Cómo podríamos conseguir una tipografía fluida? ¿Utilizando **viewport units** quizás?... no vais mal encaminados.

**Viewport units** es un tipo de medida que está relacionada al tamaño de la ventana (alto o ancho) de manera fluida, y no solamente para el uso en tipografía, si no también, para otros elementos. Utilizando esta técnica, nuestro anterior ejemplo se reduciría a:

```css
html {
    font-size: 2vw;
}

.title {
    font-size: 2rem;
}
```

OK, WHAT??? ¿Qué ha pasado? ¿Por qué hemos eliminado los _breakpoints_ de nuestro código?

Con **Viewport units** no es necesario el uso de *breakpoints* ya que, como hemos comentado, es un tipo de unidad fluida relacionada con el tamaño de la ventana. En este caso con el ancho, ya que como habréis imaginado (o ya sabéis), existe **vh** (viewport height) que es la unidad de medida dependiente del alto de la ventana. Podríamos pensar que hemos encontrado el Santo Grial! Pero... vamos a darle una vuelta de tuerca.

¿Tenemos un control real sobre nuestra tipografía?

Si lo pensáis bien, las posibilidades son pocas. Solamente podemos declarar el tamaño del **Viewport unit** y el tamaño de la ventana hace el resto, por supuesto, podríamos añadir breakpoints que nos ayuden, pero estaríamos en la misma situación anterior. En el siguiente ejemplo podéis ver qué pasa con un tamaño de fuente más pequeño y uno más grande.

<iframe allowfullscreen="allowfullscreen" frameborder="no" height="500" scrolling="no" src="//codepen.io/italodr/embed/jVRboK/?height=500&amp;theme-id=0&amp;default-tab=css,result&amp;embed-version=2" style="width: 100%;" title="Test - fluid typography" width="300"> See the Pen Test - fluid typography by Italo Devoto Ramella (@italodr) on CodePen.</iframe>

_So close_ 😔, pero vamos a darle una vuelta más, necesitamos decirle a la tipografía que debería tener un tamaño mínimo y uno máximo... podemos hacerlo pero hace falta más que solamente el uso de **vw** y aquí entra en escena **calc**... (y [Mike Riethmuller](https://twitter.com/mikeriethmuller)) Lo que Mike hizo fue crear una función utilizando **calc**, unos tamaños de tipografías y unos breakpoints mínimos y máximos. Tomemos como ejemplo un tamaño de tipografía mínimo de `16px` y uno máximo de `32px`, que se hará fluida desde los `480px` hasta 1200px`.

```scss
.title {
    font-size: calc(16px + (32 - 16) * ((100vw - 480px) / 1200));
}
```

lo traducimos en variables y la función se convertirá a:

```scss
.title {
    font-size: calc(
        $min-font + ($max-font - $min-font) * ((100vw - $min-breakpoint) / $max-breakpoint)
    );
}
```

Con algunos matices, ya que como podéis ver en el ejemplo, algunos valores no llevan las unidades para poder realizar las operaciones matemáticas necesarias. Y aunque parezca una fórmula muy compleja, en realidad es una fórmula que se utiliza en otros sitios y lenguajes de programación, como por ejemplo para mapear valores, y que podemos encontrar en [Arduino](https://www.arduino.cc/en/Reference/Map). Pero hay que concederle el mérito a Mike por integrarlo con la función de CSS: **calc**. Ahora viene lo más interesante de todo, poder utilizarla en nuestro código.

Por supuesto, no tenemos que añadir esta línea cada vez que lo necesitamos. En este _Pen_ tenemos un ejemplo de la **fluid typography** utilizando un simple `@mixin` de Sass. Otro detalle es que no solamente se puede realizar de menor a mayor si no también a la inversa. 😊 **WIN WIN**

<iframe allowfullscreen="allowfullscreen" frameborder="no" height="500" scrolling="no" src="//codepen.io/italodr/embed/KNYVrj/?height=500&amp;theme-id=0&amp;default-tab=css,result&amp;embed-version=2" style="width: 100%;" title="Fluid Typography" width="300">See the Pen Fluid Typography by Italo Devoto Ramella (@italodr) on CodePen.</iframe>

El @mixin de Sass que utilizamos en [Runroom](https://www.runroom.com) ❤️

```scss
@mixin fluid-type($min-font-size, $max-font-size, $min-vw: 480px, $max-vw: 1200px) {
    $u1: unit($min-vw);
    $u2: unit($max-vw);
    $u3: unit($min-font-size);
    $u4: unit($max-font-size);

    @if $u1 == $u2 and $u1 == $u3 and $u1 == $u4 {
        font-size: $min-font-size;

        @if $min-vw != $max-vw {
            @media only screen and (min-width: $min-vw) {
                font-size: calc(
                    #{$min-font-size} + #{strip-unit($max-font-size - $min-font-size)} *
                        ((100vw - #{$min-vw}) / #{strip-unit($max-vw - $min-vw)})
                );
            }
        }

        @media only screen and (min-width: $max-vw) {
            font-size: $max-font-size;
        }
    } @else {
        @error "Detected mixed units. Please use the same units for all parameters.";
    }
}

@function strip-unit($number) {
    @return $number / ($number * 0 + 1);
}
```


Artículos

Cómo obtener un certificado SSL en localhost

Auditoría de dependencias con Yarn

Constant FORCE_SSL_ADMIN already defined

Fluid Font Type