Hoy me gustaría hablar de webpack, me gustaría un poquito desmitificar, eso es lo primero, de webpack, de que mucha gente dice que es muy complicado, hay que configurar muchas cosas y es verdad, es cierto que de alguna forma puede ser bastante complicado y tiene una configuración muy avanzada,
pero para empezar desde cero a mí personalmente no me lo parece, no me parece que para empezar desde cero haya que hacer cosas muy complicadas, pero es cierto que las versiones anteriores, sobre todo la primera, la webpack 1, ahora vamos por la 4 y van a sacar la 5, en webpack 1 es verdad que la configuración era muy difícil,
digamos que tenía que tener sí o sí un archivo de configuración y eso hacía pues que se complicase un poco la cosa, ahora ya no es tan complicado, al menos si quieres hacer una aplicación que sea sencilla y entonces una de las cosas que quiero es desmitificar esto de que webpack es tan, tan, tan difícil,
que hay tweets muy graciosos que dicen, he estado 4 horas para configurar webpack, bueno, vamos a intentar que no sea tanto, entonces para los que os estéis metiendo ahora en el live coding, en este streaming, webpack es un empaquetador de aplicaciones,
básicamente, mira, tengo aquí una caja que me va a servir un poco de ejemplo, esta caja de aquí, ¿vale? Al final, esto sería webpack, esto sería lo que queremos hacer, ¿no?
webpack al final es una cajita y aquí pues vamos metiendo todo lo que queramos, a ver, ¿por dónde se abre esto? Esto se abre por aquí, entonces, ¿qué podemos tener aquí?
Pues decimos, bueno, pues nuestro archivo JavaScript, este por aquí, ¡hala! ¡pum! Una imagen que necesito, ¿vale? Pues por aquí y al final lo que hacemos es empaquetar nuestra aplicación,
todas las dependencias que tengamos las metemos a esta cajita y así pues la podemos distribuir como un estático a nuestros usuarios. ¿Por qué necesitamos webpack? Eso lo vamos a ver ahora,
vamos a ver desde el principio, sobre todo, ¿por qué necesitamos este tipo de herramientas hoy en día? Y yo creo que con este pequeño ejemplo lo vais a entender.
Antes de ver este ejemplo y empezar a ver un poquito de código, me gustaría también comentaros una cosita sobre webpack.
Al final, webpack es tan complicado como lo queramos hacer porque podemos importar nuestros módulos de JavaScript,
pero también podríamos hacer que pudiésemos importar CSS, que es bastante normal, SAS, Style Components,
podríamos hacer imágenes, archivos de texto que fuesen planos, ¿no? Un TXT, por ejemplo, y que webpack de alguna forma pues lo pudiese tratar.
Y eso, a través de eso, lo podemos complicar todo lo que queramos, pero al final lo que es lo más básico de webpack es empaquetar
aplicaciones que importen módulos de JavaScript. Tan sencillo como eso. A partir de ahí lo podemos complicar, lo que queramos y mucho más.
Así que voy a compartiros por aquí mi pantalla. Tenía por aquí el editor. A ver, voy a guardar esto aquí. A ver si soy capaz.
Aquí, en stringer. Vamos a ver. Esto lo pongo aquí. Vamos a ver cuál es el que puede quedar.
Eh, muy chiquitito. Aquí, más grande. Vale, sí. Tenía yo aquí ya mis archivos creados. Tengo aquí unos cuantas cosas.
Esta es la página oficial de webpack. Básicamente es lo que dice, ¿no? Empaquetar tus imágenes, tus scripts, todo lo que tengas.
Al final es esto. Es lo que vemos aquí a la izquierda, ¿no? Que es que todas las dependencias que, digamos, que tiene nuestra aplicación,
todos estos son módulos y lo que hace es resolver todas estas dependencias y empaquetarlas. De forma, esto sería webpack lo del medio, pasa por webpack
y lo que nos da son estáticos que podemos deployar más fácilmente en un servidor, ¿no? Y así, de esta forma, lo podría consumir un usuario desde el navegador.
Está muy bien porque puedes ver aquí, pues, que no solo son javascripts, que sería lo más normal, sino que tendríamos, estos son templates de handlebars,
o sea, podríamos hacer plantillas. Estos son archivos de SAS, esto es una imagen y a través de unos loaders que podemos ver,
que luego os explicaré un poquito este concepto, pues, a partir de los loaders podríamos tratar todos estos tipos de ficheros.
Pasaría por webpack y nos lo simplificaría de forma que lo podamos deployar por estos archivos estáticos, ¿vale?
Pues, esto sería un poco webpack. Luego tengo aquí un montón de algunos tabs abiertos para enseñaros algunas cosillas,
pero vamos a ver cómo podemos empezar y por qué es importante utilizar webpack hoy en día.
Vamos a ver. Voy a ver si la terminal tengo aquí en Dev y voy a crear un webpack LiveCoding.
Voy a hacer un poquito más grande, que seguramente no se verá mucho.
LiveCoding y aquí voy a abrir el editor. Vamos a poner el editor aquí, justo al lado de nuestro...
Lo voy a poner así, que se quede blanco por ahora, ¿vale?
Yo aquí voy a abrir la terminal y así, pues, estaremos aquí concentrados en nuestra terminal.
Lo primero que voy a hacer en este directorio es, pues, nada, inicializar el proyecto con npm init y barra i.
No sé si veis bien el texto. Decidme si veis bien el texto, si lo veis muy chiquitito o si tengo que hacer algo más grande
para que lo veáis guay. Vale. npm init y el guión i, que básicamente es para inicializar el proyecto
y que no nos haga ninguna pregunta. Vale. Muy bien.
Con esto, ya lo que nos ha creado, podéis ver aquí que nos ha creado un package.json.
Package.json, pues, es donde vamos a instalar todas las dependencias y tal.
Bueno, por ahora vamos a olvidarnos un poco del package.json.
Lo que voy a hacer es crear un directorio que le voy a llamar source por ahora.
Y en source voy a crear otro archivo que le voy a llamar index.js e index.html.
En el html, pues, voy a crear este template.
Esto que he hecho, que mucha gente me lo pregunta, dice, pero ¿cómo puedes escribir tan rápido?
No. Es que hay una, como un shortcut, ¿vale? Del editor de Visual Studio Code,
que si pones una exclamación y le das al enter, ya te crea todo esto y la verdad es que está bastante bien.
Vamos a poner webpack paso a paso y por ahora en el body vamos a poner un elemento, un div,
que sea, pues, no sé, una app, que es lo más típico.
Y por ahora vamos a poner estamos trabajando en ello.
Estamos trabajando en ello. Vale.
Por ahora no estamos haciendo nada de webpack.
Vamos a pensar que esto es una página web normal y corriente.
Yo tengo un alias aquí para levantar, pues, páginas estáticas, que se llama Surf, que utilizo Servor,
que en el último live coding lo expliqué y os recomiendo mucho que, lo vamos a abrir aquí un momentito,
y así, pues, al que no estuvo en live coding, pues, que lo sepa.
Y es una herramienta, bueno, es un programa, un click, un command line que es bastante interesante,
que lo que te permite es levantar una carpeta que tenga archivos estáticos,
que tenga un index.html y poderlo ver.
Además tiene diferentes opciones, está muy bien.
Entonces, bueno, podéis hacer, o lo podéis instalar, podéis hacer un npm install-g-server,
por ejemplo, para empezar rápidamente, o lo podéis poner como en el paquete.
Yo tengo un alias que es muy interesante, que es Surf, y ya le digo, pues, el directorio,
en este caso sería Source.
Si no lo tenéis, no tenéis un alias, por supuesto, me imagino que no tendréis el alias.
Lo que podéis hacer es Servor, tendréis que decirle qué carpeta queréis,
que en este caso sería Source.
Le decís el archivo que servirá de fallback en el caso que no encuentre la ruta,
que es index.html, el puerto donde lo queréis abrir, en este caso, pues, 8080 o el que prefiráis.
Voy a hacer esto un poquito más chiquitito.
Ahí.
8080 y luego le podéis decir si queréis que haga un reload cada vez que cambie los cambios.
O sea, cada vez que haya cambios en los archivos, lo modifiquéis.
En este caso, por ahora, es lo único que queremos, ¿no?
Queremos hacer esto.
Servor, ya me ha abierto el puerto, 8080, voy a entrar, lo copio y lo pongo aquí.
Vale, bueno, todavía no hemos visto nada de webpack, pero ya tenemos este servidor desde cero.
¿Por qué quiero que veamos todo esto?
Vale, os lo voy a explicar.
Ahora tenía este index.js.
Este index.js, pues, aquí vamos a hacer algo, ¿no?
Por ahora no vamos a hacer nada porque lo que vamos a hacer es crear otro archivo que le vamos a llamar hi.js, que va a funcionar para poder saludar.
En el HTML habíamos dicho que teníamos este div, ¿no?
Con app y estamos trabajando en ello.
Vale, pues, lo que este hi va a hacer es tener una función, que sea say hi, y que lo que debería hacer es cambiarnos el contenido de este div.
Vale, pues, lo que vamos a hacer es coger el elemento document.getElementById y cogemos este elemento app, le cambiamos a innerText y aquí ponemos, pues, vamos avanzando.
Vamos avanzando.
Perfecto.
Guardamos los cambios y hasta aquí, pues, ¿cómo podríamos hacer que podemos?
O sea, me gustaría utilizar esta función que tengo en este archivo, me gustaría utilizarlo en el index.js.
Me gustaría aquí hacer un hi, bueno, era say hi, me gustaría hacer esto, ¿no?
Y ejecutarlo, me gustaría ejecutar este método.
Pero, claro, ejecutar este método así no es tan fácil.
¿Cómo cojo la referencia?
¿Cómo tomo esta referencia del hi.js en este archivo?
Vale, antiguamente, y por qué es tan importante que se crease el webpack, lo que podríamos hacer, y lo vamos a solucionar ahora,
si guardo los cambios, bueno, ahora funciona exactamente igual, vamos a poner un script aquí que tome el index.js.
Vale, guardamos los cambios y ya podemos ver aquí en la consola que nos dice, a ver si puedo hacer más grande, hay,
en la consola nos está diciendo que el say hi, pues, no funciona, say hi no está definido.
Claro, porque si voy a index.js, pues, no está encontrando este método por ningún sitio, porque está en otro archivo.
Entonces, cómo funcionaría esto es que tendríamos que poner antes de este script cargar el de hi.
Si guardamos los cambios, vale, ahora nos dice que no puede hacer un set de null porque, y esto también es bastante interesante, ¿no?
¿Qué está pasando? Me dice que no puede hacer un set de un null porque la propiedad inner text no la encuentra y tal.
¿Qué pasa? Que estamos cargando el script antes de que el elemento exista.
Y como se está bloqueando la carga del script, no encuentra el elemento, se está ejecutando en orden.
Primero es el hi.js y luego es el index.js y luego tenemos el html.
Por lo tanto, al parsearse el html no está encontrando ese elemento.
Tenemos que mover estos scripts aquí abajo.
Ahora guardamos los cambios y ahora sí ha funcionado todo.
Pero ya hemos podido ver que hemos tenido unos cuantos problemas, ¿no?
Podemos ver que hemos encontrado el problema de tener que mover los scripts de sitio y que además las dependencias,
y ya empezamos con un poco la nomenclatura de Webpack, ¿no?
Las dependencias que necesitamos en index.js tenemos que cargarlas manualmente aquí, ¿no?
Tenemos que decirle, no, quiero primero que este script esté cargado y esté disponible para poder utilizarlo en index.js.
Además, es un poco tricky porque, claro, ¿qué pasa si yo tengo otra dependencia, ¿no?
De mi aplicación que le puedo llamar también otra, .js, y resulta que tengo otra función que también se llama así.
Pero esto hace otra cosa, hace otra cosa.
Y guardamos los cambios y resulta que tenemos cargados los dos archivos.
Así que ponemos aquí el otra.
Claro, ¿qué pasa?
Que ahora hace otra cosa, pero yo no estaba esperando que me hiciese otra cosa.
Yo lo que esperaba es que me mostrase la otra cosa, ¿no?
O sea, me mostrase lo del principio.
Lo que quiero que veas aquí, que te quede claro, es que el problema es que hay una colisión que no estamos controlando, ¿no?
Que de alguna forma se nos está escapando de nuestro control.
Y es porque esto, en realidad, está en el contexto global.
El hecho de que index.js sea capaz de ejecutar este método es porque en el contexto global tiene disponible este sayHi.
Así que aquí en window.sayHi tenemos esta función.
Claro, esto da bastantes problemas porque dependiendo del orden en el que cargamos hi.js o otra, pues ya estamos cargando una cosa u otra, ¿no?
Entonces, esto es bastante problemático. Se rompe con demasiada facilidad.
Hasta aquí podemos ver cuál sería la necesidad que nos está dando el desarrollo de aplicaciones.
Claro, esto es una aplicación muy sencilla, muy pequeñita.
Pues imagínate con una aplicación con un montón de dependencias, con miles de dependencias,
porque cuando hacemos un npm install, pues la de archivos, la de cosas que hay ahí,
si tuvieramos que trabajar con este tipo de contextos y este tipo de colisiones.
Así que lo primero que me gustaría enseñarte es que le vieses realmente cuál es el valor que tiene y por qué lo necesitamos.
Es cierto que podríamos cambiar un poquito esto.
Podríamos utilizar módulos y de hecho lo vamos a hacer para que funcione.
Utilizando módulos, que es algo de cómo cargar scripts reciente y que lo vimos en el anterior live coding,
pues vale, podríamos hacer el type module hasta aquí.
Y ahora aquí podríamos borrar esto.
Ahora en el index.js deberíamos hacer un import de justamente el que queríamos,
que estaría en high.js.
Y en high.js lo que deberíamos hacer es exportar esta función.
Y ahora podemos ver que vamos avanzando.
Y le voy a poner una exclamación para que veas que realmente está funcionando correctamente.
Hasta aquí esto es bastante mejor, porque ahora sí que tenemos como el punto de entrada de nuestra aplicación,
que es de un tipo módulo y le decimos el index.js.
Y le decimos al index.js, vale, index.js importa el módulo sayhigh del archivo high.js y entonces podrás ejecutar esta función.
Si yo borrase este import de aquí, pues no podría ejecutarlo.
Tengo que importarlo porque es la única forma de saber que tengo esa dependencia.
Así que tengo este sayhigh, perfecto, que lo estoy exportando de aquí.
Y de hecho, lo mejor de todo esto es que si yo tuviese aquí este otra y quisiese cambiarlo,
podría decirle, bueno, ahora lo voy a importar de otra.
Pero al menos lo estaría controlando yo porque sabría de dónde viene esta.
Tengo que hacer un export default también en otra.
Hacemos export default.
Al menos soy yo el que estoy controlando la dependencia que tiene que utilizar.
O la de otra o la de high.
Pero al menos decimos una u otra.
Pero es la que yo digo, ¿no?
La que hay en un contexto global y todo esto.
Vale.
Hasta aquí todo claro.
Os habéis callado todos de golpe.
Ha sido como, no sé si se esperaba que fuesen por aquí los tiros.
Pero por aquí va bien.
Este sería un poco, os he enseñado primero la forma antigua de gestionar las dependencias.
Un poco lo que viene, que son los módulos.
Pensad que este tipo de módulos hasta hace poco no estábamos trabajando con esto
y por eso era bastante imperioso utilizar Webpack.
Pero vamos a ver que con Webpack todavía tenemos bastantes ventajas porque nos va a hacer ciertas cosas que necesitamos para nuestra aplicación.
Así que, muy bien.
Por aquí en el chat, Elvis dice que pone atención.
Todo claro.
Me tiré el otro día tres horas para eso.
Pues si también hemos empezado con Webpack.
Se entiende perfecto.
David García.
Hola, David.
Todo claro.
Perfecto.
Se entiende.
Estoy trasteando.
Yo también con el VS Code.
Jaja.
Perfecto.
Muy bien.
Para los que preguntáis si se va a quedar grabado, se queda grabado un vídeo.
En cuanto termina el live coding, está disponible.
Así que no os preocupéis, que siempre están disponibles.
Vosotros, pasaos por el canal, que están ahí.
Que no os tenéis que preocupar.
Vale.
Hasta aquí.
Perfecto.
Entonces, ¿qué queremos hacer?
Tengo aquí una chuleta de los puntos que quiero ir tocando.
Así que, genial.
Vale.
Voy a parar.
Bueno, no voy a parar esto.
Voy a abrir otra pestañita por aquí.
Esta la voy a dejar aquí.
Y vamos a empezar a instalar nuestras dependencias.
Vamos a instalar Webpack.
Y la otra que vamos a instalar es Webpack Click.
Y esto son dependencias de desarrollo.
Esto es importante.
Lo que queremos es hacer este guión de o guión guión save dev para decirle que son dependencias de desarrollo.
Y ahora verás por qué es importante.
Porque cuando esto termine, que seguramente será dentro de media hora, pero bueno.
No, espero que no sea dentro de tanto.
Cuando esto termine, veremos que nos ha actualizado el package JSON y nos ha puesto las dependencias donde debe ser.
¿Vale?
Mientras esto se instala, voy a ir leyendo.
Particularidades de configurar Webpack en multipage applications.
Si no me da tiempo hoy, porque alguien me ha escrito un correo, si hoy no me da tiempo, haré un vídeo de cómo configurar Webpack con multipage applications.
En el que básicamente es tener más de un punto de entrada.
Luis, gracias, gracias.
Y me gusta mucho cómo explica las cosas.
No siempre coincido con los directos.
No te preocupes.
Todo clarinete.
Genial.
Gracias.
Y dándome feedback un poco porque si no me siento aquí solo que no sé a quién estoy hablando y tal.
Así que así me siento un poco acompañado.
Vale.
Ya se ha instalado.
Perfecto.
Entonces, lo primero que queremos hacer para utilizar Webpack es ir al package JSON.
Vemos aquí que tenemos en el dev dependencies.
Nos ha instalado las dependencias, ¿vale?
En modo desarrollo, que es lo que queremos.
Y vamos a añadir un nuevo script que le vamos a llamar build.
Y aquí simplemente lo que hacemos es ejecutar esta nueva dependencia que hemos hecho que es Webpack.
Así que guardamos los cambios y ahora podemos hacer un npm run build.
Vale.
Y esto ejecuta Webpack.
Vamos a ver qué es lo que ha hecho Webpack por aquí.
Desde que he hecho el npm run build, ha ejecutado Webpack y ya ha encontrado el archivo que quería transformar.
Ha hecho algún tipo de cosa.
Ahora veremos qué es lo que ha hecho.
Y me ha dado un warning y me ha hecho, oye, que sepas que el modo que me has dicho, bueno, no me has dicho ningún modo,
así que yo he entendido que es producción y he tirado millas, pero si quieres puedes cambiarlo y tal.
Vale.
Entonces, la primera pregunta sería, capa chao, ¿no?
Capa chao, yo he ejecutado Webpack y esto ha funcionado solo de gratis.
Yo no he hecho ninguna configuración.
Pues no te preocupes que lo vas a entender.
Lo primero es que Webpack ya funciona con unos valores por defecto en su configuración.
Y por defecto lo que va a hacer es buscar como punto de entrada de tu aplicación en la carpeta source el archivo index.js.
Pero, ¿qué es esto del punto de entrada de la aplicación?
Y empezamos con un concepto que debe ser clarísimo que tengas en Webpack.
Y hay cuatro que tienes que dominar.
El primero, entry, que es el entry point, que es el punto de entrada de la aplicación.
Imagina que Webpack en realidad es como una maraña de dependencias, ¿no?
Tu aplicación depende de una dependencia, depende de otra dependencia y la dependencia tiene que tener a lo mejor 15 dependencias, ¿no?
Pero lo importante al final es por dónde empiezas.
Una vez que empiezas es tirar del hilo.
Vas tirando del hilo y dices, ay, vale, yo he empezado con mi index.js, por ejemplo, teníamos el index.js y el index.js siendo el punto de entrada de la aplicación ha hecho un import de otra dependencia.
Luego, que esa dependencia importe otras dependencias ya no importa.
Eso ya lo irá resolviendo.
Pero lo que le tenemos que decir a Webpack es por dónde tienes que empezar y a partir de ahí tirar del hilo.
Así, punto de entrada de la aplicación.
Cuando antes estaba comentando que quería comentar en otro vídeo lo de multipage application, es porque al final podrías tener más de un punto de entrada en tu aplicación.
Podrías hacer que además de un index.js tuvieses otro.
Son casos más avanzados, pero podría ocurrir.
Así que, punto uno, punto de entrada de la aplicación.
En nuestro caso, por defecto, source barra index.js es el punto de entrada.
Por eso ha funcionado totalmente de gratis, sin ningún tipo de configuración.
Ahora, ¿qué más cambios ha hecho?
Una vez que ha terminado esto, ya podemos ver una cosa.
Y es que ha encontrado, ha dicho, vale, aquí he encontrado este source.index.js, que es el punto de entrada de nuestra aplicación.
Y fíjate que ya ha recorrido ese hilo.
Y ha encontrado que en el index.js estamos haciendo un import de esta dependencia de high.js.
Así que, de alguna forma, ya ha resuelto eso.
Ahora, ha creado una carpeta llamada dist.
Vamos a ver qué tiene esta carpeta.
Tiene un archivo que se llama main.js.
Y aquí tenemos otro concepto que es importante, que tenemos que controlar y que también tiene, por supuesto, un valor por defecto.
Que sería el output.
Que básicamente es decirle, oye, webpack, ¿dónde me tienes que dejar todas estas cosas que has resuelto?
Desde este punto de entrada, todas sus dependencias.
Cuando lo has hecho una cajita, ¿cómo se llama esa cajita?
¿Vale?
¿Y dónde me la vas a dejar?
Pues, por defecto, donde deja esa cajita con todas las dependencias es dentro de la carpeta dist en el archivo main.js.
Y esto es lo que tiene el main.js.
El main.js, que tiene un montón de archivos muy extraños, ¿vale?
Que no nos tenemos que preocupar porque esto es un poquito magia que tiene webpack.
Aquí tiene algunas utilidades del propio webpack.
Pero, al final, podemos encontrar que sí que tiene el contenido de nuestros módulos.
Aquí tendríamos, por ejemplo, el contenido del hype.js.
Y esto, digamos que lo ha hecho de una forma que lo podrá entender súper fácil el navegador.
Que cuando queramos importar este archivo, funcionará sin ningún tipo de problema.
Entonces, mira, preguntan por aquí.
Inma me dice, ¿qué sentido tiene que tener varios puntos de entrada?
He explicado que tenemos uno, pues, podríamos tener varios y es un caso avanzado.
Pues, porque hay aplicaciones, cuando es una aplicación que es una single page application,
es muy sencillo porque normalmente todo es un punto de entrada y dependiendo de la ruta,
pues, es siempre la misma aplicación.
Luego ya cargará diferentes dependencias.
Pero cuando no es una SPA, puede ocurrir que tú quieras tener la página home y la página listado totalmente separadas.
Entonces, cuando las quieres separadas, puedes tener el punto de entrada solo de la home
y un punto de entrada solo del listado o del detalle o de la búsqueda o de lo que sea.
Puedes tener más de una página y cada página tiene diferentes dependencias.
A lo mejor en la home estás cargando React y en la parrilla, pues, estás, la parrilla o la búsqueda,
estás cargando Angular, por ejemplo.
No es habitual, pero sí que es habitual que puedas tener eso, sobre todo en sistemas que todavía no están en monolitos o lo que sea
y quieren pasar a utilizar, pues, este empaquetador y luego, más adelante, a lo mejor pasar a una SPA.
Vale, pues, vamos con ello.
Nos hemos quedado con el main.js, teníamos esto.
Y, entonces, ¿qué podemos hacer para que ya nos funcione esto?
Lo que podemos hacer es crear aquí el archivo index.html y le copiamos el mismo contenido que teníamos aquí.
En el source se lo vamos a pasar al dist del index.html.
Solo que ahora no tenemos que cargar este script de type module y tal.
Lo único que tenemos que hacer es cargar el main.js.
Esto más adelante veremos cómo lo podemos solucionar para que no sea así.
Bueno, aquí, ahora, vamos a hacer este server, esto que había hecho antes, que os había comentado,
para levantar un entorno de desarrollo y decirle qué carpeta queremos levantar.
Ahora vamos a decirle que queremos el dist.
Así que voy a ejecutarlo y vamos a ver en el puerto 8080 qué es lo que me ha dejado.
Vale, es exactamente lo mismo.
Nos ha dejado exactamente lo mismo.
Lo importante es que funciona.
Si miramos aquí en el código fuente, esto sale muy grande,
puedes ver que está cargando el main.js.
O sea, está cargando ya lo que ha bundleizado, el bundle de nuestro webpack, el main.js.
Lo que vamos a ver a partir de ahora en nuestro navegador es después de haber hecho el paso de compilación.
Hasta aquí ya estamos utilizando webpack, por ahora cero configuración.
Muy bien.
Así que ahora vamos a solucionar el problema este que nos ha comentado, ¿no?
Nos ha dicho, eh, warning, en la configuración no has puesto nada del modo y lo he puesto producción por defecto.
Vale.
Pues lo que vamos a hacer es ir al package.json y aquí vamos a añadir otro script.
Vamos a poner uno que sea dev y lo que le vamos a decir es que será webpack y el modo que va a tener este va a ser development.
El otro que hemos dicho que era build, para solucionar el warning ese que nos decía, le vamos a decir que era producción.
Así que vamos a tener como dos modos de empaquetar nuestra aplicación, ¿no?
Una de producción y otra de desarrollo.
Vamos a ejecutar ahora este npm run build.
A ver qué nos dice.
Y ahora no nos ha dado ningún warning.
Si vamos a ver el main.js, pues es exactamente igual.
Pero si ahora ejecutamos un npm run dev, que es el que habíamos dicho, vamos a ver qué pasa.
Vale.
Pues puedes ver que el main.js que nos ha dejado no está para nada optimizado, ¿no?
Nos ha dejado un montón de comentarios, nos ha dejado las cosas sin minificar.
¿Qué está pasando, no?
Vale.
Por defecto, webpack, digamos que tiene este modo de producción porque lo que esperas es que lo que vas a empaquetar, pues,
esté lo más óptimo posible para que lo puedas enviar a un servidor y esté, vamos, perfecto para que la destransferencia sea la mínima.
Pero, ¿qué pasa?
Que a la hora de trabajar en esa aplicación, si tú quieres ver algún error, es un poquito más críptico.
Entonces, este modo de desarrollo, que además es un poquito más rápido a la hora de compilar porque hace menos optimizaciones,
lo que te permite es que si hubiera algún error en nuestro código, podríamos ver fácilmente dónde se encuentra.
Nos daría esa maraña complicada, ¿no?
Y nos diría, vale, pues aquí es donde tenemos el problema y ya está.
Vale.
Así que tenemos el modo de desarrollo y el modo de producción.
Hasta aquí, sin ningún tipo de configuración ni nada y sigue funcionando.
Vamos a quitar esto.
Por ahora todo claro.
A ver si todo lo vemos bien.
A ver, voy a ir borrando, cerrando tareas por aquí y vuelvo a abrir el paquete y eso.
¿Todo bien?
Sí.
¿Qué dice por aquí?
Sí, alguien le decía que era posible cuando trabajabas en código legacy.
Me dice Manuel, ¿recomiendas más webpack o la herramienta de crear React App para una aplicación con React?
En el vídeo de hoy vamos a terminar con la aplicación de React.
Vamos a terminar haciendo JSX y React para que veáis cómo funciona un loader
y vamos a ver también un plugin y tal.
Entonces, yo creo que es interesante.
Wow, 154 conectados.
Hola a todos.
Hola a todos.
Sois un montón.
A mí me parece súper interesante utilizar, entender cómo funciona webpack.
Sobre todo lo que quiero hoy es que entendáis por qué existe, cómo funciona.
No es tan complicado para empezar, es verdad que luego se va complicando, pero creo que puede ser interesante aún así ver cómo funciona.
Porque si queremos controlar las herramientas y que las herramientas no nos controlen a nosotros,
por ejemplo, cuando Create React App se actualice o tengamos que hacer una actualización o si alguien nos pide,
oye, me gustaría entender esto, pues creo que está bien.
Aún así, obviamente Create React App está súper bien.
O sea, es una herramienta que está muy bien hecha, que es de Facebook y por supuesto está muy bien mantenida.
Así que yo diría que para algo rápido utilizaría Create React App,
pero si yo tuviese que hacer una aplicación para una empresa muy tocha, muy grande,
yo seguramente haría webpack y me lo configuraría, bueno, al máximo, con todo el tipo de tener un fine tuning, ¿no?
O sea, afinarlo al máximo a mis necesidades.
Al final, por ejemplo, Create React App, pues de salida no tiene soporte a server-send rendering
o hay algunas actualizaciones que no las tiene.
Pues claro, yo creo que está bien, al menos puede ser la base, pero a partir de ahí, pues ir mejorando, ¿no?
Y pues tener la posibilidad de que cuando quieras moverte de ahí, pues que sepas cómo funciona más o menos.
Vale, hasta aquí todo bien.
Entonces, ¿qué quería hacer aquí?
Una de las cosas que es bastante importante controlar es que con webpack podemos escuchar los cambios.
También tiene un modo que es Watch.
Vamos a ver si esto funciona.
Pero debería ser, en el modo de desarrollo, decirle, vale, pues voy a escuchar continuamente los cambios.
Porque como puedes ver, he estado ejecutando a mano, ¿no?
Cada vez que quería que me hiciese un build.
Entonces, podría decirle el npm run dev y ahora debería quedarse así.
No me ha devuelto al prompt del terminal.
Porque le he añadido esta opción, este parámetro, Watch.
De esta forma, ahora, conforme vaya escribiendo, si ahora le cambiamos, voy a poner esto un poquito más grande, vamos avanzando en webpack.
Y lo guardo.
Aquí están pasando diferentes cosas.
La primera.
Mira, webpack ha visto este cambio y ha vuelto a empaquetar nuestra aplicación.
De esta forma, pues podemos ver el cambio inmediatamente.
Así que cada vez que cambiamos este archivo, pues está volviendo a compilarlo, ¿no?
En dist nos está dejando el main.js, lo vuelve a compilar.
Y como hemos dicho al principio que teníamos esta herramienta, este programita, que era el de server, el de server lo que está haciendo es cada vez que hay algún cambio en esta carpeta de VIST, yo me refresco.
Y eso es lo que está haciendo.
Entonces, hay una cosa que a mí me sorprende particularmente y ahora luego lo explico.
Pero hay una cosa que me sorprende.
Hay mucha gente que se vuelve muy loca configurando webpack para poder hacer esto.
Esto que acabamos de hacer.
¿Por qué?
Porque es verdad que existe la posibilidad de utilizar webpack devserver.
Es totalmente cierto y es súper lícito.
O sea, y lo vamos a ver.
Pero, como puedes ver, hay una forma bastante sencilla de conseguir que webpack te vaya compilando, hacer un watch sobre los archivos y esto te genere un output y ver los cambios directamente en el navegador sin ningún tipo de problema.
No es tan óptimo porque esto lo que nos está haciendo es crearnos los archivos.
Y veremos después que webpack devserver lo que hace es dejarlo en memoria.
Pero ya hemos visto hasta aquí que esto lo está haciendo bastante fácil.
Vale.
Hasta aquí ya tenemos el watch.
Así que ya podríamos estar escribiendo, trabajando, ir viendo los cambios.
Perfecto.
Ahora, lo que queremos, voy a crear otra terminal aquí.
Lo que nos gustaría ahora es, por ejemplo, poder trabajar con React, con JSX.
No es tan importante, ahora mismo no es importante que sepamos React y de hecho no voy a entrar al detalle de React.
¿Vale?
Pero imaginemos que queremos utilizar React porque esto nos va a dar pie a utilizar un loader y a explicar el loader seguramente más interesante y más utilizado que hay en webpack que, por supuesto, es el de Babel.
Así que vamos a instalar React y React.
De nuevo, no es importante que separe React y igualmente, pues, así lo veis y creo que puede ser interesante.
Ahora, en el index.js, pues, lo que nos gustaría es importar React.
Vamos a ver.
Import React from React.
Y vamos a importar este ReactDome desde la dependencia de ReactDome.
Vamos a guardar los cambios y ya podemos ver que está detectando que hemos importado React en nuestro proyecto porque nos está recomendando utilizar la extensión de las herramientas de desarrollo.
Pero todavía no he hecho nada con React.
Así que ahora vamos a decirle que ReactDome vamos a hacer, esto es muy sencillo, es decirle, lo que queremos renderizar y dónde lo queremos renderizar.
Pues, vamos a poner aquí, que vamos a poner hola mundo y lo queremos renderizar en la aplicación, ¿no?
Donde estamos diciendo hola, pues, ya no decimos hola.
Este say hi lo vamos a eliminar porque ahí lo que queremos renderizar es esto.
Hola, mira, hola mundo con React.
Y hacemos esto y guardamos los cambios.
Ya está, ya está, ¿no?
O sea, ahora hemos instalado React y lo único que hemos tenido que hacer es importar React, en este caso ni siquiera React es importante, pero ahora veremos porque sí que lo necesitamos.
Hemos importado ReactDome y le hemos dicho, renderiza este texto aquí, ya está.
He guardado los cambios y todo ha funcionado sin ningún tipo de problema.
Me pregunta Oscar Fuentes qué tan confiable es el watch de Webpack.
La verdad es que es bastante confiable y ahora mismo es bastante óptimo.
Al principio en Webpack 1 y Webpack 2 sí que tenían algunos memory leaks, pero ahora funciona perfectamente siempre y cuando hagas cambios en los archivos en los que estás trabajando.
No esperes que detecte cosas mágicas.
Pero si es dentro del source, dentro, cualquier archivo que esté tocado en ese grafo de dependencias, a partir del punto de entrada va a detectar el cambio y va a volver a hacer el build.
Vale, entonces, hasta aquí bien, React, pues parece que funciona y todo esto.
Vale, uno de los problemas que tenemos aquí es que para utilizar JSX tendríamos que utilizar Babel.
Entonces, aquí me gustaría utilizar JSX.
El que no sepa qué es JSX al final es como utilizar un createElement, solo que te lo transforma y tal.
Lo que tienes que entender aquí, que es importante, es que este archivo, tal y como está en JavaScript, no tiene sentido.
Si yo pongo aquí un h1, así, y aquí hacemos esto, y guardo los cambios, esto no es JavaScript al uso, esto no existe, porque esto es JSX, esto no tiene sentido.
No es importante que sea JSX, lo que es importante es que a partir de ahora vamos a querer transformar este archivo en algo que sí que entienda el navegador.
Y para hacer eso necesitamos el concepto de loader.
Así que ya puedes ver que yo he guardado los cambios con este JSX que he puesto aquí y me ha dado un error en la consola.
Me ha dicho, oye, a ver, perdona, es que esto está muy bien lo que estás haciendo, me parece maravilloso,
pero aquí te has pegado una fumada porque hay un token que no entiendo ni yo ni nadie y esto no es JavaScript válido.
Claro, es que ya nos está avisando, ¿no? Dice, puede ser que necesites un loader apropiado para cargar este tipo de fichero.
Así que mira a ver cómo lo puedes hacer.
Los loaders, aquí tenemos el tercer concepto.
Recordemos, entry, por todo el punto de entrada de nuestra aplicación, output, que al final es donde dejamos nuestro paquetito,
y al tercero, loaders.
¿Qué son los loaders?
Básicamente, los loaders son el, es como un túnel por el que van a pasar todas las dependencias que nosotros importemos.
Por defecto, la única dependencia que Webpack es capaz de entender son, como hemos visto, los JavaScripts.
Si yo intento hacer aquí un import de un archivo que no entiende, como este, que ahora, aunque era un JavaScript, ya no lo entiende.
Ya dice, esto parecía JavaScript, pero cuando lo he intentado importar, la sintaxis no es correcta.
Si yo intentase hacer, por ejemplo, también un import de un fichero normal, de un TXT, de una imagen o lo que sea,
eso no lo entiende, ¿no?
El Webpack no lo entiende, se lo intenta, se lo pasaría al navegador y el navegador tampoco lo entendería.
Lo que necesitamos son los loaders.
Cada vez que hacemos un import, cualquier fichero con el que hacemos un import pasa por un loader.
Así que hay un montón de loaders.
De hecho, hay una página que os recomiendo muchísimo que es muy interesante, que es Amazon Webpack, creo,
que es el típico repositorio con un montón de cosas.
Y puedes encontrar diferentes loaders que tiene Webpack, porque como te puedes imaginar,
tienes loaders para todo, para cargar SVGs, para cargar URLs, para cargar JSONs.
Entonces, aquí teníamos loaders y tenemos por tipo de ficheros, tendríamos componentes y templates, estilos, lenguajes, para TypeScript,
cualquier cosa que quieras cargar directamente que se tenga que transformar para que la entienda, tienes que utilizar un loader.
¿Vale?
¿Por qué te marca el string como error?
A ver, ¿cuál, cuál, cuál?
¿Cuál es el que me marca?
O sea, con este, decís este, este error, este error en realidad no es el string, sino es este h1, ¿no?
Porque este h1 no lo entiende.
Está diciendo, oye, no estoy entendiendo a qué te refieres con este h1, ¿no?
Esto no es JavaScript, este token que has hecho aquí no tiene sentido.
De hecho, cuando quito esto, si quito esto y esto lo pongo en un string, esto va a funcionar perfectamente,
porque esto sí que lo entiende.
¿Vale?
Hasta aquí, bien.
Así que, hasta aquí.
Me preguntan, ¿webpack con React y TypeScript?
Claro, sin problema.
O sea, al final los loaders, además los loaders puedes hacer que uno pase por, que se haga uno,
lo que hace ese luego se lo pase al otro.
Eso es muy típico, por ejemplo, cuando cargas SAS.
Tienes un loader que carga SAS y de SAS se lo pasa a post CSS y de post CSS se lo pasa a style loader
y entonces hay diferentes loaders.
Entonces, ahora que tenemos esto, lo que tenemos que instalar es el loader de Babel.
¿Qué Babel lo que nos va a hacer?
No sé, me imagino que lo conocéis todos.
Pero Babel lo que es, es un compilador que básicamente coge JavaScript y te lo transforma a otro JavaScript.
Normalmente, el JavaScript que tú escribes, o que quieres escribir en tu aplicación,
es JavaScript que es el del futuro, que le digamos, ¿no?
Que es JavaScript que todavía no entiende el navegador, pero que tienes muchas ganas de utilizar.
Pero no solo es eso, por ejemplo, JSX es como un pseudo lenguaje que tendríamos ahí,
que está basado en XML y lo que queremos es que Babel nos lo transforme a realmente un código que sí que entienda.
En este caso, por ejemplo, esto, que no entiende, queremos que nos lo transforme,
voy a poner un comentario, esto, lo que queremos es que nos lo transforme a esto.
Que esto sea un h1 y que esto, ahora el type object, primero son las props, vale, y luego debería ser el, esto,
hola mundo con React.
Esto va a hacer a mano el createElement, que es un poco, no, esto no lo he hecho bien.
Esto creo que es así, sí, vale.
Lo que vamos a hacer es transformar esto, que es lo que le estamos pasando, a esto.
Lo que queremos es que haya una transformación y para que haya transformación lo vamos a hacer con el loader.
Queremos que nos pase, nosotros escribimos esto y lo que queremos que le llegue al navegador,
queremos que le llegue esto.
Y esa transformación nos la va a hacer Babel, ¿vale?
Para que esto sí que funcione.
Así que vamos a comentar este y vamos a dejarle el otro para ver si estamos haciéndolo bien.
Vale, guardamos los cambios.
Ahora, no está funcionando, vamos a empezar a instalar las dependencias que necesitamos para que esto funcione.
Primero, npm install y Babel.
Babel core.
Y luego vamos a poner Babel, luego Babel loader.
Babel loader es el loader de JavaScript que hay de Webpack.
Lo vamos a poner aquí y aquí podéis ver el loader y este sería el oficial además de Babel, ¿vale?
Babel loader.
Y luego, además, vamos a instalarle un preset que va a ser Babel preset react.
Y esto lo ponemos como dependencias de desarrollo, importante.
Vale.
De hecho, aquí ya nos va poniendo la documentación.
En este caso está haciendo el preset env.
Nosotros lo vamos a poner por ahora solo el de preset react.
Los presets básicamente son un montón de reglas preestablecidas que ya tiene Babel para que podamos hacer una configuración u otra, ¿vale?
Podríamos hacerlo a nivel de plugin o a nivel de preset.
Al final, un preset son un montón de plugins.
En el preset de react, una de las transformaciones que tendrá será justamente la que queremos, que es la de JSX.
Ahora sí, el problema es que podríamos llegar a hacer funcionar esto sin ningún tipo de configuración, pero vamos a crear la configuración que necesitamos de Webpack para que esto sí que funcione.
Así que vamos aquí a nuestro proyecto y tenemos que crear un archivo que sea webpack.config.js.
Aquí lo que vamos a hacer es hacer un import de, bueno, no hace falta ni siquiera hacer un import, lo podemos hacer después.
Por ahora vamos a hacer un módulo.exports, que esto básicamente es decirle que el módulo que queremos exportar es lo que vamos a hacer ahora.
Aquí hay dos diferentes formas de hacer, así que podemos o bien hacer una función, que la haremos después, que es bastante interesante, o podemos hacer directamente un objeto.
Vamos a hacer el objeto.
Esto es nuestra configuración ahora mismo y es lo que tenemos.
Lo que tenemos que decirle es que el módulo que tiene que utilizar depende de unas reglas.
Las reglas que queremos hacer son un array.
En este caso le decimos, entre las reglas que tenemos, tenemos una que lo que tiene que hacer es testear un archivo en concreto.
Porque esta transformación no queremos que ocurra en todo tipo de transformación, solo queremos que ocurra en los archivos que a nosotros nos interesa.
En este caso, como es Babel, solo queremos que ocurra en los archivos que son de JavaScript.
Aquí, bueno, aquí tenemos este test, que básicamente es el que tenía en el Ritmi, pero es un poquito más complicado ese porque está también pensando en m, j, s.
Esto es como una regex.
Al final podríamos hacerlo, yo creo que más sencillo.
No sé si esto funcionaría.
Podríamos probarlo.
Luego lo probamos, a ver.
Pero si no, lo que podemos hacer es, esto es una regex, pero es bastante sencilla de entender.
La regex es porque empiezan estos dos símbolos y lo que le decimos es que busque .js, cualquier archivo que termine con .js.
Es lo que estamos diciendo.
El símbolo del dólar es indicar que termina ahí el string, ¿vale?
Bueno, el string, lo que está buscando.
Así que .js, cualquier archivo que termine con .js es el que queremos que haga, que pase por aquí, por Babel Loader.
Este exclude que hace aquí es el de los no de módulos porque no queremos que haga esta transformación en los módulos que estamos instalando.
Lo primero porque si no, esto tardaría bastante.
Y luego porque no es necesario normalmente.
Aquí le decimos lo que tiene que utilizar.
Cuando esta regla pase, ocurra, ¿qué es lo que tiene que utilizar?
Pues lo que tiene que utilizar es el Loader de Babel Loader y entre las opciones que tenemos que cargar en este Loader, que esto ya es un poco las opciones de Babel, esto no tiene ya nada que ver con Webpack.
Ahora son opciones que le vamos a pasar directamente a Babel, ¿vale?
Así que en las opciones le decimos, vale, las opciones es que tiene que utilizar un preset que será Babel, preset, React.
Vamos a hacer esto un poquito más pequeño.
Esto así, perfecto.
Esto es todo lo que queremos hasta ahora, ¿no?
Queremos, le estamos diciendo, vale, carga este módulo, tienes un montón de reglas y entre esas reglas hay una que cuando encuentres un archivo que termina con .js, ¿vale?
Me excluyes todo lo que haya en los 9 módulos, pero si no están los 9 módulos y tiene este .js al final, quiero que utilices un Loader, que será Babel Loader y las opciones que tienes que utilizar para este Loader, para cada uno de los archivos que pasen por ahí, es este preset de Babel preset React.
Así que esta sería nuestra configuración por ahora.
Así que vamos a la otra pestaña.
Ahora esto es importante.
Hay que, normalmente hay que volver a refrescar, tienes que cerrar Webpack y volverlo a abrir o no entenderá, claro, no va a coger la configuración nueva al vuelo, no la va a tomar y ya está.
Sino que tienes que cerrar y volver a abrir.
Así que, en pionrandef, está mirando los archivos e importante, si miramos en la, esta es la última ejecución, esta es la última ejecución, pero si vemos la anterior, ¿vale?
Si vemos la anterior, puedes ver que nos estaba dando un error que no entendía un token.
Nos decía, oye, que he intentado parsear, empaquetar todo esto, pero esta dependencia que he tomado aquí, pues no la he entendido, así que, pues no he podido hacer esto.
Me ha dado un error y ahí te quedas, ¿vale?
Pero ahora que hemos añadido esta configuración, ahora que sí que hemos hecho este en pionrandef, ahora no nos ha dado ningún error.
No nos ha dado ningún error porque esto sí que le ha ayudado a entenderlo.
Lo que ha hecho Webpack es, vale, este archivo ha macheado, perfecto, pues lo que voy a hacer es pasarlo por este loader, no sé lo que hará este loader, Webpack no tiene ningún tipo de visibilidad, eso es una caja negra para Webpack.
Lo importante es que ese loader ha hecho algo con el archivo, se lo ha devuelto a Webpack y ahora sí, es JavaScript plano y lo entiende.
Y al entenderlo, lo ha empaquetado, ya está.
Es importante eso, ¿no?
Webpack no, o sea, Webpack como tal no entiende de Babel, no entiende de nada.
Esos son loaders que son cajas negras para Webpack y hacen la magia que tienen que hacer para que Webpack, que eso no entiende JavaScript plano, funcione y ya está.
Perfecto. Voy a mirar, perdón, voy a mirar aquí un momento el chat porque he visto por aquí que había un montón de cosas y vamos a ver.
Néstor Ramírez dice que es nuevo con Webpack y hasta ahora todo claro, espero poder usarlo en mi próximo proyecto.
Ya con lo poco que hemos visto, con lo poquito que hemos visto, ya podrías utilizar Webpack y realmente habría cosas bastante interesantes.
Vamos a ver, excelente herramienta, no la conocía, dice Anarchi, pues no sé dónde te has metido porque Webpack está por todos lados.
Joan Miao dice, watch, magia.
No es magia, la es watch, al final es solo un parámetro que le pasas y es verdad que tiene un poquito de, que por detrás lo único que hace es detectar los cambios que hay en un fichero,
en los ficheros que estás utilizando en tu proyecto y cada vez que ve que hay un cambio, pues lo único que hace es volver a ejecutarse.
Webpack con React y TypeScript se puede perfectamente, hoy seguramente no nos dará tiempo, pero le haremos un vídeo sobre eso que me parece bastante interesante.
Si quiero depurar desde la consola de Chrome, Webpack me pondrá el bundle o el código fuente que estamos escribiendo.
Eso tampoco creo que nos dé tiempo, pero podemos ver que con Webpack al hacer el bundle puedes hacer que, aparte del archivo que vas a darle al navegador,
te deje un source map que se llama, que básicamente es un archivo que tiene o las indicaciones necesarias para entender mejor el código minificado
o directamente un archivo que tiene el código real, mientras que el que tú sirves es el minificado.
O sea, tú le sirves el minificado y Webpack además hace un source map que es donde está todo el código realmente y que sí que se puede leer.
Es bastante interesante, además hay diferentes estrategias porque una es todo el código, que es bastante más lento,
otra es solo decirte en qué líneas es el error, pero no está el código entero, o sea que tiene un montón de cositas.
Hay gente que dice Webpack o Grant.
Grant es un poquito más antiguo y además no es exactamente el mismo concepto.
Grant al final lo que haces tú son scripts que se van ejecutando,
pueden ser con diferentes conversiones y transformaciones, pero es otro rollo diferente.
Porque aquí en Webpack lo que tú tienes es un gráfico de dependencias, le tienes que decir el punto de entrada
y a partir de ahí funciona.
En Grant, que igual hace mil años que no lo tocó, pero al final lo que sí que podías hacer era transformaciones y tal,
pero no tanto entender estáticamente tu aplicación, sino a partir de hacer tareas y transformaciones
sin llegar a entender ese árbol de dependencias que tenía tu aplicación.
Igual estoy equivocado, pero que yo sepa era así.
Vale, entonces, vamos con esto, vamos a volver para atrás.
Esta es nuestra aplicación con Webpack.
Vamos a quitar esto y esto.
Vale, ahora, pues claro, ya está, porque esto, es que esto ya está funcionando.
Esto ya está funcionando, porque como tiene el modo Watch, pues aquí podéis ver, funcionando, funcionando la transformación.
Vale, bueno, es muy grande, me he pasado con el, vamos a poner un H3.
Vale, ya está funcionando perfectamente este JSX.
Entonces, imaginemos que ahora, pues ya tenemos la transformación de JSX, perfecto.
Pero, de verdad, esta configuración es bastante pequeña y lo poco que hay en realidad no es tanto de Webpack.
Es verdad que le estamos diciendo esto, pero además que hay una cosa que a mí me sorprende,
es que la gente no se para muy bien su archivo de configuración y al final son pequeños monstruos que no son necesarios.
Por ejemplo, podríamos decir, aquí tenemos los módulos, tenemos las reglas y podemos decir Babel Rules o, por ejemplo, solo por ya...
Lo podemos dejar aquí.
Al final este módulo Rules, esto podemos decir que está aquí y ya está.
O sea, tenemos por un lado las reglas que hemos dicho que tienen nuestros archivos de JavaScript y simplemente esto sería la configuración que necesitamos.
Así que hasta aquí tampoco es tan tan complejo, ¿no?
O sea, tenemos unas reglas que son para los archivos de JavaScript y le decimos que tenemos un módulo y que las reglas, pues es un listado y una de ellas es la de JavaScript.
Ya está.
Vale.
Entonces, también podría ser que queramos hacer algún tipo de transformación del JavaScript más allá de React, que igual tendría que haber empezado por aquí.
Pero no sé si lo conocéis, pero hay uno que hay una nueva sintaxis.
Es que claro, el problema es que Chrome, como puede con todas las sintaxis, yo creo que seguramente esto funcionará sin ningún tipo de transformación.
Lo podemos mirar, pero podemos hacer, si esto es así, punto, nada, es que, no, vale, está perfecto.
Vale.
¿Qué está pasando aquí?
Lo que he puesto es utilizar el optional chaining.
El optional chaining lo que te permite es comprobar si existe una propiedad o un objeto.
Por ejemplo, aquí le decimos, este objeto que tiene la kia y el valor 1, si intento acceder a este hola, esto me debería funcionar o no me debería funcionar.
En lugar de hacer esto, sería un poco como hacer esto.
Similar, no es exactamente lo mismo.
Pero, en lugar de hacer esto, ahora se puede hacer, pues, simplemente esto.
Y de esta forma, pues, podríamos hacer que no sea tan largo comprobar si existe una propiedad en un objeto.
Así que, bueno, al final este objeto no es necesario que sea así.
Entonces, tenemos el mismo problema de antes.
Nos dice, vale, pues, he tenido un problema parseando este módulo porque no entiendo el token.
Y el token que no entiendo está justamente en esta línea.
Y, por lo tanto, pues, no lo he podido compilar y me he quedado así y tal.
Pues, volvemos un poco a lo mismo.
Esto ya es un problema totalmente ajeno a Webpack.
Es un problema más de Babel.
Así que, lo que podemos hacer, optional chaining, es añadir la, podemos hacer una o que soporte la sintaxis o hacer realmente la transformación.
No sé si en, a ver si alguien lo sabe, si esto, por ejemplo, sí, sí, en Chrome ya funciona.
Es que en Chrome se toman tan rápido los cambios en el lenguaje.
Es brutal lo rápidos que son.
Vale, pues, el tema.
Podríamos hacerle que soporte la sintaxis porque esta sintaxis ahora mismo no la está entendiendo Babel.
Y podríamos decir, bueno, pues, soporta la sintaxis y no la transformes.
O le podemos decir utilizar el proposal.
Que esto lo que haría es transformarlo.
Vale, la diferencia sería, podemos ver, ¿queréis ver las dos diferencias?
Voy a utilizar el plugin Syntax y si me decís que queréis ver las dos diferencias, lo hacemos.
Y podemos ver en el código exactamente dónde está la diferencia.
Lo que prefiráis.
Lo que voy a hacer por ahora es instalar este plugin que es de Babel.
¿Vale?
Y vemos cómo solucionamos el problema haciendo que Babel sí que entienda esta sintaxis.
Y cuando pase, la deje pasar sin ningún tipo de problema.
¿Vale?
Por ahora es eso, la sintaxis, ¿vale?
Así que ahora he instalado la dependencia de este plugin, plugin Syntax, para la sintaxis del Optimal Chaining.
Y lo que vamos a hacer ahora en estos presets, le vamos a añadir también los plugins.
Y como plugin, lo único que tenemos que decir es que queremos utilizar este,
que va a soportar la sintaxis del Optimal Chaining.
Así que ahora, si volvemos a ejecutar el modo Dev, pues vuelve a apretar.
¿Vale?
A ver, ¿por qué ha apretado esto?
Vamos a ver.
Ahora me ha dejado aquí muy loco.
Babel, Syntax, esto...
Saludo.
Es de mejor de las dos formas, porfa.
Sí, si consigo arreglar el primero, lo hacemos de las dos formas.
¿Vale?
Files, sí, mira que me está diciendo que lo está procesando con el loader correcto, ¿eh?
Pero aún así no me lo ha pillado.
¿Vale?
Esto es el interrogante con el punto.
Esto lo voy a quitar, que no tiene nada que ver.
Y vamos a ver otra vez.
Vale.
Sí, está andando ahí.
Con el...
Hola.
Vale.
Pues esto en realidad...
No sé si será porque no entiende el propio webpack.
Pero en principio con esto debería ser suficiente.
Vamos a probar con el momento con el Proposal.
A ver si con el Proposal funciona.
Zoom.
Install.
En modo...
Es una menos D porque es una dependencia de desarrollo.
¿Vale?
Y vamos a ver si en plugins...
Esto.
Vamos a probar con esta.
A ver si sí que hace la transformación.
Y ponemos en pionrandef.
Si alguien ha encontrado el problema, que lo cuente, ¿eh?
El del Syntax.
Vale.
Con el Proposal sí que funciona.
Bueno, la verdad es que ahí me ha dejado un poco loco.
Pensaba que iba a funcionar soportando las syntaxes.
Pero a lo mejor es el propio webpack que no lo entiende.
Ahora lo podemos probar.
Bueno, lo que vamos a ver con este, que al final he utilizado la propuesta.
La propuesta, la diferencia entre syntax y Proposal es que Proposal sí que hace la transformación.
Entonces, si vamos al dist y miramos el main, y aquí entre todo lo que ha compilado,
cuando buscásemos este punto hola, aquí puedes ver cómo sí que ha hecho la transformación.
Si no hubiese hecho la transformación aquí, lo que hubiera dejado es esto.
Es como que hubiera soportado la sintaxis, pero no lo hubiese transformado.
Es como que lo hubiese dejado pasar.
Pero ya veo que me ha dejado bastante roto y no ha funcionado.
Pero bueno, al menos ya puedes ver cómo deberías ir añadiendo plugins si tienes algún tipo de necesidad específico.
Luego, el típico preset, que no es el de React, que también habría que instalar, es el de env.
Que básicamente es el que hace todas las transformaciones para que controles todo el JavaScript
que ahora mismo está de alguna forma aceptado por el JavaScript.
Así que podremos instalar de Babel, preset, env.
Y esto se lo añadimos en los presets.
Le ponemos que aparte del de React, pues también tenemos el preset env.
Y así lo que hará es transformarnos absolutamente todo el JavaScript para que lo entiendan todos los navegadores.
Por defecto, creo que llega hasta Internet Explorer 11.
Pero bueno, esto es una cosa que es interesante solo si queréis dar soporte a este tipo de navegadores.
Así que ahora envío en Randev.
Y pipipi, ya estaría haciendo.
De hecho, si vamos aquí y miramos qué transformaciones ha hecho,
pues veríamos que está haciendo todavía más transformaciones.
Hay una pregunta bastante buena aquí que dice,
si tiene varios plugins, ¿puede influir el orden?
Sí que puede influir el orden.
Y de hecho es interesante a veces.
Puede influir el orden, pero es raro que influyan porque normalmente se toleran bastante bien.
Pero sí que puede llegar a influir el orden de los plugins.
Y sobre todo el del que sí que influye es el de los loaders.
Hay algunos que tienen que tener un orden.
Por ejemplo, si vas a importar un archivo SAS,
primero es el SAS.
Luego podrías hacerle los cambios de post-CSS.
Y luego podrías utilizar el style loader,
que eso te lo captura y lo puedes meter en tu página.
Pero si te importas un SAS y le dices que lo primero que tienes que utilizar
es el post-CSS, que es para archivo CSS,
pues entonces te petaría y no te funcionaría.
Vale.
Entonces, hasta aquí está bastante bien.
Hemos visto que la configuración que hemos tenido que hacer es bastante pequeñita.
No hemos tenido que hacer gran cosa.
Pero la configuración por defecto trae cosas que son bastante interesantes,
como hemos visto.
Pero a lo mejor queremos hacer más cosas.
Nos gustaría poder transformar mejor el archivo.
En lugar de que nos deje un main, pues ponerle otro tipo de nombre.
Así que aquí le podríamos poner output y decirle cómo queremos que sea el output de este archivo.
Si vamos aquí en workpack, el output, y miramos qué configuración se le puede pasar.
Vale.
Dicen que por aquí que el main.js es enorme.
¿Cómo debugueas eso?
Realmente es enorme porque no tiene ningún tipo de optimización.
¿Vale?
Ahora estamos en modo desarrollo.
Pero si lo pones en modo producción es mucho más pequeño.
Pero igualmente para debuggar, justamente mejor que sea grande y que esté todo bien separado,
cada uno por su línea y todo perfecto.
¿Vale?
Entonces, aquí en el output, pues tendríamos...
Bueno, es que esta configuración del output es un poco rara.
A ver aquí, si nos sale el output.
Vale, aquí tenemos la configuración.
Podemos ver la que es por defecto.
Además, la documentación de webpack ha mejorado un montón.
Ahora podemos ver, cuando le damos, nos da acceso directamente a esa sección
y vemos diferentes propiedades que tiene esa configuración.
La de module ya la hemos visto.
La de las rules es la que hemos utilizado antes.
Pues ahora estamos con la de output.
Y la de output, ahora lo que nos gustaría, pues es poder decir que en lugar de ser main,
sea otro, ¿no?
Le podríamos decir, vale, pues el filename, en lugar de main, pues vamos a decir que es app.js.
Y guardamos los cambios.
Y si ahora hacemos el mpm run dev, ahora nos ha creado el output con otro nombre, app.js.
Y hay un problema, y empieza a haber un problema con esto y ahora lo vamos a ver.
Y es que ahora tengo que cambiar el index.html, ¿no?
Ahora tendría que volver a cambiar aquí, ¿no?
Y entonces volvería a funcionar, pero he tenido que hacer un cambio manual.
Además, y esto es una cosa bastante potente de Webpack, que es bastante interesante
y que no podríamos hacer de la otra forma, aquí tiene como unos comentarios especiales mágicos
para poder meterle hashes.
Que con esto, lo que nos permitiría, por ejemplo, sería decirle,
cada vez que hagas este tipo de configuración de bundleizado,
quiero que me detectes qué hash has hecho a través del contenido.
¿Por qué?
Porque, claro, si tú quieres cachear ese estático y haces un deploy a las 5 y haces un deploy a las 6
y lo cacheas para siempre, el usuario del segundo deploy no va a ver los cambios.
Necesitas que cada estático tenga un hash único, ¿no?
Porque si no, de esta forma no va a funcionar correctamente.
Entonces, lo que puedes utilizar son estos chunk hash, que lo que te permitiría,
en este caso sería un hash, hash, ahí está,
que lo que te permitiría es como calcular a través del contenido un hash único para ese fichero.
De esta forma, como puedes ver ahora, nos ha creado este archivo app.unhashenorme.js.
De esta forma, cada vez que hagamos un cambio, si yo ahora hago un cambio aquí, por ejemplo, en el index,
y vamos a hacer esto un poquito más chiquitito, vamos a quitar esto, borramos esto, ¿vale?
Borramos.
He guardado los cambios, el watch me ha vuelto a hacer un build y entonces me ha creado otro fichero,
pero imagínate que digo, ah, no, es que este texto no era funcionando a transformación, ahora es funcionando.
Guardo otra vez, me ha creado otro fichero con otro hash.
Pero, ¿alguien me podría decir cuál es el problema que tendríamos con esto?
Vale, el problema que tendríamos con esto, alguien me está diciendo, no es hash, es content hash.
Y tiene razón, es content hash.
Con content hash estaríamos, básicamente el problema, lo que me gustaría que viese,
es el problema del index HTML, ¿no?
Porque ahora, aunque yo estoy haciendo aquí y cada vez que compilo me va generando estos hashes,
en el index.html yo siempre estoy apuntando a .js, que de hecho, aunque ahora nos está haciendo,
cada vez que hacemos un bundleizado, nos está haciendo la limpieza de todo el directorio,
si yo me pongo a cambiar aquí, ¿vale?
Y, por ejemplo, vamos a quitar todo esto.
El problema ahora es que cada vez que hace un empaquetado, mi fichero no tiene ya sentido.
Ahora, cuando hago esto, me genera el app .hash.js y resulta que no me va a funcionar,
que ahora esto me va a decir que no está encontrando el fichero.
Esto es un problema.
Es un problema porque yo manualmente, si quiero hacer un deploy, no puedo dedicarme a,
vale, vamos a ver qué hash hay aquí.
Pues este hash me lo voy a copiar en index.html.
Vale, eso no es para nada escalable.
Además, ahí veo que en el chat hay gente que está,
¿el hash lo haces para evitar problemas de caché?
Sí, como he comentado, lo hago para tener problemas de caché,
para evitar, para, si quiero cachear ese estático,
quiero que sea un fichero único.
Y de esta forma, pues cada vez que cambie ese fichero,
no tenga el problema de que hay usuarios que todavía ven la versión anterior.
¿Vale?
Así que utilizar los hashes, que esto es una cosa interesante que nos da Webpack,
es súper importante.
Así que, ¿cómo soluciono esto?
Pues esto lo vamos a solucionar utilizando el concepto de plugin,
que es el cuarto concepto que necesitamos dominar también para dominar totalmente todo lo que es Webpack.
Hemos dicho, punto de entrada de la aplicación.
Los outputs, el loader, que ya lo hemos visto, y para finalizar, los plugins.
¿Qué son los plugins en Webpack?
Vale, pues los plugins son una maravilla, porque hacen de todo.
¿Vale?
Los loaders, como hemos visto, hacen una cosa en concreto,
que cada vez que haces un import, pues los transforma a los ficheros
y le hace lo suficiente para que lo pueda entender el navegador y lo pueda tratar y tal.
Pero los plugins lo que hacen es ejecutar código en diferentes puntos de Webpack.
Tiene unos hooks, ¿vale?
Que Webpack dice, estoy preparando este fichero, ya lo he preparado,
ya he hecho esto, ahora voy a copiar el fichero, ahora voy a crearlo,
ahora voy a eliminarlo, ahora voy a hacer, ¿vale?
Tiene diferentes puntos de ejecución Webpack, ¿no?
Desde que empieza el punto de entrada hasta que hace el output del fichero,
pues tiene un montón de cosas que ejecuta ahí en medio.
Entre lo que va ejecutando, esos puntos, digamos,
son donde se van a ejecutar algunos plugins, donde tiene estos hooks.
Entonces, lo que vamos a hacer ahora es utilizar un plugin,
que es el HTML Webpack Plugin.
Y vamos a ver cómo lo podemos hacer.
Vamos a ir un momento, plugin, plugin, a su documentación.
Y además con esto no necesitaremos, a partir, bueno,
dentro de poco no necesitaremos hacer lo de levantar el entorno de desarrollo.
Vamos a instalar este plugin, que lo que nos va a permitir
es crear al vuelo un HTML.
En lugar de tener nuestro HTML, que lo tenemos que crear a mano,
lo que vamos a hacer es crearlo automáticamente.
Y además vamos a utilizarlo con el plugin que necesitamos.
Uy, se me ha quedado el ratón ahí en medio.
Ah, vuelve.
Ahora.
Se me ha quedado, sí, no sé si hay una zona ahí oscura,
que se queda un poco rara.
A ver, voy a mover cosas.
A ver si así se...
Ahora, mejor.
Ah, vale.
Pues ya se ha instalado el plugin y lo que vamos a hacer con este plugin
es añadirlo.
Lo más increíble de este plugin es que es un plugin que,
a su vez, tiene más plugins.
Tiene una de cosas que te puedes volver muy loco.
Pero para nosotros lo único interesante va a ser añadirlo en nuestra
configuración tal y como está y ver qué es lo que nos ofrece.
Así que aquí ahora vamos a añadir plugins.
Y el plugin que queremos cargar lo tenemos que importar primero aquí
arriba, lo vamos a importar.
Y vamos a decir const html webpack plugin,
que es el que nos va a permitir hacer un html al vuelo y que además va a estar
apuntando al bundle correcto sin nosotros tener que hacerlo manualmente,
que es un coñazo.
Claro, que es un coñazo, no, que no es escalable de ninguna forma.
Y le decimos esto, plugins, y lo utilizamos así con html webpack plugin.
Entonces, aquí hay diferentes opciones, pero esto es porque lo tienen así.
Lo importante es que nos dice que va a generar este dist index.html conteniendo tal.
Vale, pues vamos a ver qué es lo que nos hace.
Voy a borrar este que teníamos aquí.
Vale, voy a guardar aquí, lo borro, voy a borrar todo el dist.
Y ahora voy a ejecutar el install otra vez, no, el mpn run dev para hacer el empaquetado
en modo desarrollo.
Importante, el dist, la carpeta la había dejado totalmente vacía.
Y ahora se ha creado este index.html.
Este index.html que ha creado, que yo no he hecho nada, lo ha creado automáticamente.
Pues resulta que ya tenemos este script que sí que está apuntando al archivo correcto.
Vale, ya lo ha añadido automáticamente.
Tiene un montón de configuración aquí que podríamos ponerlo donde nosotros queramos
y hacer lo que queramos y tal.
Pero por ahora la he puesto así y ya nos sirve.
Ahora, vamos a hacer este serve del dist del index.html y vamos otra vez al 80.80.
¿Qué está pasando aquí?
Vale, el problema que está pasando aquí, hay un error que nos dice que no encuentra el contenedor.
Y no encuentra el contenedor porque resulta que este index.html no lo tiene.
Yo cuando en el source, en mi index.html con el que hemos empezado,
¡Ey! No quiero salir.
Con el que hemos empezado, yo tenía este div app y había puesto, estamos trabajando en ello.
Pero, ¿tú ves en algún sitio le estamos trabajando en ello?
No.
No, porque no le estamos diciendo al HTML webpack plugin cuál es el template que queremos que utilice.
Y por defecto está utilizando uno que no nos está sirviendo.
Si vamos aquí a su documentación y vemos la diferente, pues, bueno, configuración que tiene, el title.
Por ejemplo, el title por defecto es webpack app.
Y si vamos al index.html que ha creado, pues el title es webpack app.
Lo podemos cambiar.
Así que aquí ya le podríamos decir que title sea webpack paso a paso.
Ahora, lo que nos gustaría es que el template que use no es ese que hace por defecto, sino que utilice el nuestro,
que ya lo tenemos en el source.
Bueno, el index.html dentro del source.
Así que vamos a poner el template y le vamos a decir que esto, en lugar del default que es, pues, vacío,
pero, ¿ves? Por defecto utiliza source barra index.ejs, que es bastante raro porque esto es un sistema de plantillas que ya casi no se usa.
Pero, bueno, así que vamos a decirle que queremos que utilice el del index.html, que es el nuestro.
Ahora, vamos a volver a poner esto.
Esto sí que sé que es un poco coñazo, que cada vez que se cambia la configuración hay que cerrar el webpack,
lo que estábamos en modo watch, y volver a levantarlo.
Es un poco coñazo, pero si no, no pilla los cambios.
mpn run dev, vamos a mirar ahora nuestro index.html.
Vale, perfecto.
El index.html que ha generado ahora sí que tiene, le estamos trabajando en ello.
Además tiene esto, que ahora lo quitaremos.
¿Por qué tiene esto?
¿Por qué tiene este script type module index.js?
¿Esto lo ha generado o qué ha pasado aquí?
En realidad no.
En realidad es que ha utilizado la plantilla que teníamos aquí,
y la plantilla que teníamos aquí, la que hemos empezado al principio del vídeo,
habíamos dejado este script.
Entonces este script no lo queremos para nada.
Ya lo podemos eliminar porque ahora automáticamente este plugin lo que va a hacer es inyectar el bundle que ha generado
y va a ponerle el hash además correcto.
Y va a decir, el bundle que tienes que cargar es este.
Así que ahora si vamos aquí, ahora sí está funcionando.
Lo que hemos hecho es generar al vuelo el html y lo mejor es que estamos teniendo aquí la posibilidad de generar este html,
pero con una plantilla, no empieza desde cero, sino que esta plantilla tiene algo.
Sí, ya me estaba diciendo por aquí, le debes indicar en el plugin el index.
Sí, lo he hecho posta para que veamos un poco el paso a paso, realmente entender de dónde sale.
No nos quiero lanzar a, no, hay que poner de primeras esta configuración.
No, me gusta que veamos por qué no funcionan las cosas y luego que luego hay cosas que no funcionan y nunca,
no es lo que quiero, pero en este caso sí, en este caso sí.
Vale, lo bueno de tener este template es que en realidad aquí podríamos poner pues que la plantilla que tenemos en el source
pues tenga sus elementos, por ejemplo, creando magia.
Enorme el título.
Y lo bueno es que una vez que lo genera, en realidad todo lo que pongamos aquí, pues lo tiene, ¿no?
Y este script lo tiene, pero también tiene los elementos que nosotros le hemos dejado.
Así que está bastante guay.
Y de nuevo, tenemos aquí, pues sé que puede parecer mucho, pero tenemos unas 27 líneas de código.
Bueno, 27 líneas de código.
Al final este plugin son dos líneas y tenemos los JavaScript rules, pero bueno, ya tenemos,
además no está generando aquí nuestro JavaScript.
Está a modo desarrollo.
Si podríamos hacerlo, que este modo producción, voy a poner el modo watch en producción,
que es un poco raro, pero para al menos que veamos cómo sería el output con producción con todo esto, ¿vale?
Vale, está viendo los ficheros.
Vale, este sería el de desarrollo que hemos generado antes y este sería el de producción.
El de producción está mucho más limpio.
Evidentemente aquí dentro de este bundle tenemos React, React DOM, nuestros ficheros.
Aquí hay un montón de cosas, aunque no lo parezca, ¿vale?
Así que no es tan fácil como parece.
Vale, entonces, nos queda una última cosa.
No sé si tenéis preguntas hasta aquí.
Si alguien te pregunta, es que las comente antes de que sea demasiado tarde
y sigamos continuando con esto, ¿vale?
Porque si no, vamos siguiendo.
Vale, mientras tenéis preguntas y las vais poniendo en el chat,
os comento por dónde vamos a seguir y lo que vamos a terminar.
Hemos visto que la configuración tampoco es tan complicada,
o a mí me lo parece, ¿vale?
Una vez que entiendes cada uno de los conceptos y para qué sirve cada uno de los conceptos.
Entonces, el tema interesante ahora es ver cómo evitamos este entorno de desarrollo
que yo he puesto al principio.
Como os he dicho, esto en realidad funciona, ¿no?
Esto en realidad sí que funciona bien para tener este entorno de desarrollo
y ir escuchando los cambios y tal.
El único problemilla que hay aquí es que no se ve muy lento, es bastante rápido,
pero cuando una aplicación va siendo cada vez más y más y más grande,
ya se empieza a complicar, ¿vale?
¿Por qué?
Porque lo que tiene que hacer es generar todos los archivos
y tiene que escribirlos en disco y escribir en disco es lento y es costoso.
Entonces, podemos utilizar una herramienta, una utilidad que tiene Webpack
que se llama Webpack Dev Server y la vamos a instalar.
Vamos a parar máquinas aquí, esto de hecho lo vamos a eliminar,
vamos a parar también esta y vamos a instalar esta dependencia.
En PM install, no, de hecho me lo había copiado.
Sí, en PM install Webpack Dev Server y lo guardamos como una dependencia de desarrollo.
Vamos a instalarlo aquí y vamos a ver.
Una de las ventajas que tiene este Webpack Dev Server es que cuando trabajas con él,
aparte de hacerte el watch y configurarlo y funcionar perfectamente,
además de todo esto, el tema es que no te escribe los ficheros en el disco,
sino que lo deja todo en memoria.
Al dejarlo en memoria es bastante más rápido, así que hay que aprovecharse de eso.
Así que en este modo Dev, en lugar de utilizar Webpack,
mod development, tal, tal, tal, vamos a poner el Dev Server.
Y vamos a guardar los cambios y vamos a decir onpm runDev y a ver si esto funciona de primeras.
Vale, vamos a ver, dice que está en el modo 8080, vamos a ir, pues ya está.
Además, este Webpack Dev Server, ahora ya no estamos utilizando para nada Server,
que es como lo que habíamos hecho al principio.
Este Webpack Dev Server, si yo elimino esta carpeta dist,
vale, y lo vuelvo a levantar, vamos a volverlo a levantar,
vale, y voy a, puedes ver que no ha generado ninguna carpeta, ¿no?
No tenemos la carpeta dist ahora, he levantado en modo desarrollo,
no ha generado ningún fichero, no está escribiendo a disco todo el rato.
Y ahora, cada vez que hagamos un cambio, si por ejemplo este, ¿no?
Tendríamos que cambiar aquí y decimos, a ver, guardamos, pues de nuevo,
ahora he cambiado, he guardado los cambios y se ha refrescado totalmente la página.
Y vamos a ver, no he hecho ningún cambio de configuración ni nada, ¿eh?
Lo único que he hecho es instalar una nueva dependencia que se llama Webpack Dev Server
y la he ejecutado, ¿vale?
O sea, no he hecho absolutamente nada.
Esto es que conecta totalmente con lo que ya tenemos de Webpack y funciona totalmente al vuelo.
¿Cuál es el problema que suele haber aquí con Webpack, Webpack Dev Server
y la complejidad que se suele añadir?
Y os, me voy a poner aquí en primera persona un momentito para comentaroslo
y me veáis en grande.
A ver, mi recomendación, no os compliquéis.
Como habéis visto, muchas de las cosas que van por defecto,
de sus opciones por defecto, funcionan perfectamente.
El problema es, a la mínima, pues, querer cambiar el entry point, ¿no?
Es que el entry point, yo no quiero que sea source barra index punto JS
porque me molesta o porque me gusta más que sea punto JS.
Al final, cada pequeño cambio que hagas ahí en la configuración
te puede traer algún problemilla que no es que sea un problema enorme,
pero te va a obligar a tocar la configuración
y eso puede provocar que tengas que tocar otra configuración a su vez.
De hecho, cuan más compleja sea tu configuración de Webpack,
es posible que Webpack Dev Server no te funcione de la nada,
no te funcione de gratis, sino que entonces ya tengas que hacer pequeñas cositas.
Entonces, mi recomendación es que para empezar en Webpack,
como has visto, no es tan complicado empezar con las cosas que vienen por defecto
y poco a poco ir añadiendo y con control las cosas que quieres.
Otro error que yo he visto normalmente
es intentar tener diferentes configuraciones de Webpack.
Y ahora os voy a enseñar una forma muy rápida de controlar las diferentes configuraciones
o los diferentes plugins que podéis cargar.
Entonces, mi recomendación es dejar las cosas,
no os copiéis las cosas de un artículo,
que este es un problema que suele pasar mucho en Webpack,
o al menos que sea un artículo que habéis encontrado en midu.dev.
No, pero en serio, hay muchos artículos que ya os están cambiando.
El punto de entrada, el public path,
os están cambiando cosas que eso al final lo que hace es complicar bastante el tema.
Dejándolo así, lo único que hemos hecho es un poquito,
le hemos cambiado el output del filename para poner el hash a través del contenido,
tenemos un módulo con diferentes reglas para los loaders y tenemos los plugins.
A partir de ahí, pues podemos ir añadiendo dentro de cada una de las secciones lo que queremos.
O sea, no sería tan difícil aquí añadir más reglas.
Por ejemplo, tenemos las JavaScript Rules y de hecho, si queréis y os interesa un montón,
podemos hacer otro vídeo donde aquí tengamos los Style Rules
y a lo mejor otros sean los Images Rules
y al final cada una de las reglas puedas tenerlas aquí definidas
y entiendas exactamente, sin hacer ahí una maraña de objeto,
de cada una de las reglas a que se refiere.
Entonces, eso por un lado.
Luego, por otro, los plugins, pues hay cosas que es mejor no hacerlas todas con Webpack.
Por ejemplo, alguien me preguntaba, ¿puedes utilizar Compression?
¿Qué Compression?
Y con esto vamos a terminar el live de hoy, solo para enseñaros un poco cómo hacer una configuración condicional en Webpack fácilmente,
sin hacer cosas muy raras, que es lo que hace la gente de poner Webpack,
que si es de producción, cargan este archivo y si no, este y lo otro.
Pero esto de Compression, aunque yo sí que es verdad que lo utilizamos en mi empresa,
mi recomendación sería, pues, al menos pensar si no es necesario hacerlo así
y hacerlo directamente con un script y tal,
porque esto te facilitará la vida al día de mañana actualizar Webpack a otra versión,
sin necesidad de hacer ninguna cosa con Webpack.
Miguel, ¿sules debugar el config de Webpack?
¿Cómo lo harías?
Sí, se puede debugar.
De hecho, puedes hacer un inspect breaking, o sea, puedes hacer,
podrías, ah, no me acuerdo un poco de la, lo tendría que buscar,
pero sí que se puede, o sea, no hay ningún problema de hacer un debug de Webpack en sí mismo.
Lo que pasa es que los cambios que haces, al final tienes que cerrar y volver a abrir,
como os he comentado, no hay una forma de hacer ese cambio en caliente
y entonces es un poco coñazo igualmente, ¿sabes?
O sea, aunque tú lo pongas en modo watch, está pillando siempre la misma configuración.
Entonces, aunque tú veas exactamente cuál es el error, tienes que cerrar y volver a abrir.
Al menos yo no he encontrado una forma fácil de evitar tener que cerrar y abrir.
¿En todos los frameworks se debe usar Webpack?
No, de hecho, en el anterior live coding visteis que el título era
¿Cómo hacer esto sin Webpack?
¿Vale? Y este es otro tema que, por favor, Webpack tiene su uso, pero no su uso en todo.
Entonces, hay veces que es interesante, pues, tanto ver cuánto de Webpack necesitas
como ver si necesitas de Webpack.
Así que creo que es interesante, ¿no?
Tener este control de ver si realmente es la herramienta que necesitas.
Para compilar SaaS necesitarás otro loader
y si usas un sistema de template como PUC u otro,
la transpilación siempre es instantánea por muchos loaders que metas.
Sí, sobre todo en el modo desarrollo, las compilaciones suelen ser bastante rápidas.
No instantáneas.
Instantáneas como ahora, sí.
Cuanto más loaders, más plugins y tal tengas, pues, peor será, claro.
Cuanto más transformaciones hace Webpack, pues, más tiempo le cuesta.
Para SaaS necesitarías utilizar SaaS loader.
Al final, además, es un loader que es totalmente oficial,
que está dentro de la organización Webpack-Contrip,
que significa que es las loaders que son de la comunidad,
pero que realmente están soportados y también ayudan a mantenerlo los propios,
el propio equipo de Webpack.
Y este sería el loader que tienes que utilizar.
Al final, esto sería, pues, un poco lo mismo que hemos visto.
Pondríamos aquí en el Webpack-Config.
Lo instalaríamos, por supuesto.
Yo pondría aquí SaaS rules, a lo mejor.
Y esto lo añadiríamos aquí.
Y ya está.
Al final, aquí es un poco especial porque utiliza más de un loader.
Tienes el de SaaS, tienes el de CSS, luego el de style.
Esto es un poco raro porque cada uno hace una cosa.
Pero el de SaaS es el que transformaría de SaaS a CSS.
El CSS loader, que este es oficial de Webpack,
lo que haría sería interpretar todo lo que tiene el CSS,
como, por ejemplo, los imports y los URLs.
El URL que, por ejemplo, puedas intentar utilizar de un archivo tuyo.
Y luego el style loader, lo que haría es transformarlo en texto.
Es el que directamente te permitiría poder utilizar ese estilo en tu página.
Aquí estaría, inyectar el CSS en el DOM.
Porque al final tendría ese texto que ya lo podrías inyectar.
Y HTML, este, el plugin, lo que haría es meterte el link con este HTML,
con este CSS.
Y así ya lo tendrías.
Al final es tener justamente los loaders que necesitas,
controlarlos y ya está.
¿Vale?
Entonces, ya para, ahora sí, que no paro de charlar.
No paro de charlar y me dais palique, pues no paro.
¿Vale?
Vamos a ver.
Vamos a terminar con lo de compresión.
Vamos a transformar esta configuración porque,
como os decía al principio, webpack teníamos un objeto y
también podíamos hacer una función.
Así que aquí podríamos hacer una función que lo que hace es
devolver este objeto.
Y aquí, en esta función, tendríamos dos parámetros.
Uno es el environment, que se le puede pasar,
y otro son los argumentos o parámetros que le hemos pasado a webpack.
Y aquí, entre los parámetros que le hemos pasado,
si miramos en el package, pues, ¿qué parámetro le hemos pasado?
El mode.
Le hemos pasado production aquí, ¿no?
Así que el mode este lo podríamos capturar de aquí.
Aquí estarían los parámetros.
Y entre los parámetros, pues, tendríamos el mode.
Y de esta forma, una cosa que podríamos hacer es tener un plugin que,
por ejemplo, si esto...
Vamos a ver, ¿cómo lo hacemos?
Esto es, pues, production.
Si es producción, pues, entonces utiliza un plugin que haga la compresión.
Por ejemplo, vamos a ver el compression plugin este que hemos dicho antes, ¿vale?
Me lo pego por aquí.
Hacemos aquí esto aquí.
¡Ay!
Ha pegado algo que no debía.
Vale.
MPM install.
Save dev.
Hacemos un install.
Y este new compression, me voy copiando un poco lo de la documentación,
que lo que hace es importar la librería, ¿vale?
La ponemos aquí arriba.
Y al final lo tenemos que añadir en plugins.
Entonces, aquí en plugins, una cosa que podríamos hacer...
Vale.
Si lo queríamos utilizar directamente, sería así.
Entonces, ¿cómo podemos hacer esto?
Lo que podríamos hacer es decirle que este plugin solo lo utilice
si el modo es producción.
Esto no estaba aprobado y tengan cuidado si lo hacen en sus casas, ¿vale?
Pero esto vamos a hacerlo así.
Y aquí al final le podríamos poner que si no, pues, false.
O le podríamos directamente...
Si vamos a hacer algo así, pues, podríamos hacer esto así.
¿Vale?
Si es producción, entonces cargas este compression plugin.
Vale.
Vamos a intentar ejecutar el MPM run build a ver qué hace y a ver qué pasa.
Vale.
Entonces, no sé si necesitará alguna configuración.
No lo he mirado, pero me imagino que no.
De hecho, aquí tenemos ya que me ha hecho el bundle y me lo ha hecho con el getzip.
Ya tenemos el bundle con el getzip, o sea, que me ha hecho la compresión.
Creo que se le puede decir también que no lo haga con Broly o que testé.
Lo mismo, ¿no?
Que solo me lo haga para ciertos archivos.
Al final los plugins son tan complicados como queramos que sean y ya está.
Vamos a ver si podemos hacer el algoritmo.
Mira, algoritmo.
Tenemos aquí getzip.
Y no se le puede pasar Broly.
Me extraña.
Ah, sí.
Yo sin Broly.
Vale.
Vale.
Lo que podemos hacer es utilizarlo más de una vez.
O sea, que podríamos decirle uno que sea este y otro que sea este, ¿no?
Le podemos decir que tenga...
Hay plugins que se pueden utilizar más de una vez.
En este caso, vamos a utilizarlo dos veces.
Uno, para que nos haga el getzip y dos, para que nos haga el de Broly.
Así que aquí lo que podríamos decirle...
Vamos a dar coger esto y le pasamos la configuración.
Que sea el file name.
Esta de query no hace falta.
Yo creo que es file name, no hace falta.
Vamos a poner esto, ¿vale?
Guardamos los cambios y ahora vamos a volver a hacer un run build.
A ver si nos hace el del Broly.
A ver.
¿Ha colado?
No ha colado.
No ha colado.
Bueno.
Bueno, lo he intentado, ¿eh?
Que no se diga.
A veces, bueno, puede ser que haya alguna configuración concreta o no sé.
Pensaba que me lo iba a hacer así de gratis, ¿eh?
Pero ya veo que no.
Bueno.
Igualmente, lo que os quería enseñar a lo del Broly es la curiosidad que tenía yo, la verdad.
Ahora vamos a probar el modo producción.
Ya hemos visto que funciona el plugin con la compresión de getzip.
Perfecto.
Ahora, en modo desarrollo, vamos a ver qué pasa.
Si teníamos este webpack mode, vamos a poner aquí que el mode ahora sea development.
¿Vale?
Y ejecutamos en pm run build.
A ver qué pasa.
¿Vale?
Vale.
Ahora está petando.
Y vamos a ver por qué está petando.
Esto está petando porque nos dice que esto está muy bien.
Webpack ha mejorado mucho a la hora de darte los errores del objeto de configuración.
En este caso, pues nos dice, oye, pues justamente dentro de plugins, pues debería ser uno de estos y lo que me has pasado no tiene mucho sentido.
Y es que si miramos la configuración, pues aquí nos estará diciendo, vale, esto, esto en modo desarrollo es false.
Y por lo tanto, false no es un plugin que sea válido.
Lo que podemos hacer, y esto es una recomendación que yo os doy, por ejemplo, sería tener todos los plugins de producción, lo podéis tener separado, o al revés, los que se dan de desarrollo, o podéis separar los que sean de producción y tal.
Bueno, el tema es que podéis tenerlo aquí, podéis poner production plugins, y aquí pues vamos a tener nuestro array, ¿no?
Production plugins, y vamos a decir que tenemos este, el new complete plugin este.
Vale, esto es production plugins.
Entonces, lo que vamos a hacer aquí es simplemente decir, mode production esto, vale.
Si hacemos esto aquí, ay no, esto no lo podemos hacer aquí, lo podríamos convertir, no pasa nada, o lo podríamos convertir en una función.
Bueno, no pasa nada.
Lo que vamos a hacer aquí es que este production plugins, que es donde pondríamos todos nuestros plugins, vale, esto, si es producción, pues lo que tenemos que hacer es cargar todos estos production plugins que tenemos aquí, ¿no?
Y en estos production plugins, que en realidad esto, hemos dicho que es un array, vale, pues el production plugins, esto sería esto aquí, lo que podríamos hacer es filtrar, básicamente.
Lo que esto debería devolver, vamos a ver lo que nos devuelve, bueno, nos va a apretar, ¿no?
Sí, igual.
Lo que deberíamos hacer es simplemente filtrar los que nos haya dado que son false.
De esta forma, este array filtrará los que den false y nos los pondrá.
Así que, vamos a ver, pim, ahora funciona perfectamente en el modo desarrollo.
Modo desarrollo, esto queda un poco raro, pero bueno, se podría extraer, ¿eh?
Una función y que quedase un poco más fácil.
Pero lo que podríamos hacer es esto, ¿no?
Poder todos los production plugins ponerlos aquí, esto lo extraemos a una función que sean los plugins de producción y ya está.
Esto funcionaría perfectamente.
Filtramos básicamente los que queremos que sean false, porque puede ser que tengamos también aquí plugins que cuando son de desarrollo, pues los carguemos, ¿no?
Entonces, ya tendríamos separados los plugins que son de producción, los que son de desarrollo y tendríamos los que son en común.
Y al filtrarlo según el modo, pues ya tendríamos una configuración aquí bastante bien mantenida, sin necesidad de duplicar reglas y, nada, tenerlo de una forma bastante elegible.
Si es producción, tengo los production plugins.
Voy a los production plugins, pues son estos.
Y ya lo tendríamos.
Ya tendríamos una configuración mirando el modo y fácilmente.
Pues no sé si tenéis preguntas, alguna pregunta por ahí, lo habéis entendido hasta aquí, hemos roto algún mito de Webpack de que tampoco es tan difícil, sigue pareciendo que está, es súper difícil.
Voy a poner aquí a que no es tan difícil.
Vamos a ver si esto cambia.
¡Ay! No ha cambiado aquí.
Vamos a ver con...
¡Ay! Me he cargado algo del...
¡Ah! Claro, es que estoy en el modo...
Ya va a estar en el modo de...
Ya está.
Empy en Randev.
Vale, empy en Randev.
Esto nos levanta en el puerto 8080.
Ah, que no es tan difícil.
¿Dejarás en un repodo este Webpack?
Por supuesto, si queréis, esto os lo dejo en un repositorio para que lo toqueteéis.
Os lo dejaré en el comentario del vídeo para que podáis estar probando lo que queráis y para que veáis que tampoco hemos hecho tanta cosa.
Sobre todo me quiero enfocar mucho a tener lo mínimo para utilizar Webpack.
Ya visteis en el anterior vídeo que no es necesario utilizar Webpack, ¿vale?
Y hay alternativas.
Por ejemplo, pues está Rollup, está Parcel y especialmente Rollup, yo diría que es para cosas muy avanzadas, muy complejas.
También se podría hacer sencillo.
Tampoco quiero ser así.
Y de hecho, las cosas avanzadas que lo pueden hacer, me gusta bastante la configuración.
Pero Parcel es una alternativa bastante interesante porque tiene cero configuración, de verdad.
Puedes configurarlo, pero no es tan necesario porque te detecta un montón de cosas.
¿Qué quieres utilizar SaaS? Pues nada, te lo instala automáticamente.
A mí me gusta mucho Parcel y de hecho tengo proyectos utilizando Parcel, pero, de nuevo, para un proyecto pequeñito haría Parcel, seguro.
¿Para el proyecto de mi empresa? Pues seguramente no.
Me gusta más tener un control más granular que me lo ofrece Webpack y que me permite optimizarlo mucho mejor y más con las necesidades que tenemos.
Esto va a gustos, ¿eh?
Y que tengo un proyecto que tiene que ser muy rápido, pues Create Recap, que utiliza Webpack por detrás.
Al final es lo mismo, pero con una configuración ya hecha, pues ya está.
Ya me solucionaría un poco el tema.
Voy a ponerme aquí en primera persona para que no me veas en chiquitito.
Bueno, entonces, me decía alguien, Oliver decía, te vas a ir sin mencionar Parcel.
No, ¿has visto? Lo he dicho.
No, y de hecho es muy buena opción.
No sé si ha salido ya la versión 2 o estaba a punto y la versión 2 tenía muy buena pinta.
Y seguramente si no ha salido, cuando salga haré un vídeo porque a mí me gusta muchísimo y me encantan las opciones que son sin configuración.
Estas herramientas, esta moda que hay ahora de utilizar las cosas sin configuración.
Pero, como podéis ver, lo que sobre todo quería era romper un poco una lanza a favor de Webpack, porque realmente es verdad que hay que ir poniendo configuración.
Por ejemplo, lo de Babel en Parcel no lo tendríamos que haber hecho, no hubiera sido necesario, pero tampoco es tanta, tanta una vez que la comprendes, ¿vale?
Y creo que es algo de software que es muy interesante, que lo conozcáis, que sepáis sus conceptos, que no os lancéis a un artículo ahí de golpe y que os diga, esta es la configuración, pégala.
Y entonces, ah, ¿qué ha pasado aquí, no? Quería ir desde cero, entender por qué surgió Webpack, que creo que es muy importante, cómo hacerlo desde cero, ir entendiendo, ir fallando y ver qué es lo que nos faltaba, ¿vale?
Y sobre todo, pues, subir un peldaño más de romper esa pared de Webpack que lo tenemos un poco estigmatizado.
¿Has usado Webpack con TypeScript? ¿Tienes algún starter en tu GitHub?
Lo he utilizado, lo he utilizado y no es muy complicado, al final, pues, es lo mismo.
TypeScript Loader, ¿vale? Y cada vez que haces un import de un TypeScript, pues, estás utilizando el TypeScript Loader, que el TypeScript Loader lo puedes pasar por Babel, lo puedes pasar por no sé qué, o no, porque TypeScript ya tiene transformaciones que vienen incluidas.
Y es exactamente lo mismo. Ya veis, una vez que te dé los conceptos claros, es, ¿quiero TypeScript? Pues, me busco mi TypeScript Loader, lo configuro y lo utilizo.
Y ya está. Seguramente haremos un segundo vídeo con otros Loaders. Si queréis, si os interesa, dejad en los comentarios de este live, pues, todos los Loaders o lo que os gustaría de ir añadiendo.
Y podemos hacer un proyecto ahí a saco de ir añadiendo Loaders, el de SAS, el de TypeScript, el que todos los que me digáis.
Y así, pues, lo podemos dejar ahí, pues, para, además, nos podemos encontrar problemas y ahí aprendemos todos, porque seguro que hay Loaders que yo no domino y, además, así, pues, aprendo.
Leonel Acosta, muy buen directo, clarísimo, además, saludos desde Argentina, saludos a todos.
Una vez más, que me he explicado todo, muchas gracias, Verónica, gracias, Mauri, muchísimas gracias a todos los que os habéis pasado por aquí, habéis estado un buen ratito.
113 y he estado una hora y 40 hablando.
Oh, my God, lo siento.
Perdón, perdón, perdón, se me ha ido de las manos. Yo me lío a hablar y es que, pero como nadie me ha avisado.
Oye, para, que me dijiste que era una hora. Vale, perdón, ¿eh?
Diego Reimi, excelente Miguel, no es lo más fácil siempre, pero pensé que era más complejo.
Sí, es que mucha gente piensa que era más complejo y creo que la culpa es de muchos artículos que a veces no es culpa dentro del artículo, sino que en versiones anteriores era así, no sé, y ha mejorado mucho Webpack y una vez que sabes los conceptos, de verdad, es mucho más claro y lo que no hay que hacer es liarse con la config y se pones ahí como un loco, ¿vale?
Muchas gracias, Diego. Marlon, excelente explicación. ¿Cuándo haría la siguiente para múltiples entry points? Es decir, no pensando van a SPA. Muchísimas gracias. Me la apunto y os prometo que hacemos, si os interesa, si queréis, si os vais a quedar y de verdad queréis, hacemos un siguiente live donde hablemos de tanto loaders como múltiples entry points y podemos seguir con este proyecto y a partir de aquí, pues, ir añadiendo todas estas cosas.
Cosas que queráis, déjamelo en los comentarios y así se queda apuntado en algún sitio, ¿vale?
Y así, pues, perfecto. Que además, si os ha gustado, compartidle un montón porque cuanto más seamos, pues, más cosas de estas haré y más me ayudaréis a seguir creciendo y, pues, más tiempo le podré dedicar a esto, que además a mí me encanta.
Ya veis que yo me pongo a hablar y no me paro. ¿Cuatro horas mínimo? No, cuatro horas. Ya hay un límite. Leo, ¿seguirás con vídeos de Svelte? Seguiré. De hecho, tengo un vídeo que tengo previsto subir, a ver si este fin de semana lo subo, que es el de las listas y quiero terminar el curso y lo terminaré.
De verdad. Inma, muy buen directo. Ha sido muy entretenido y he aprendido mucho. Se ha pasado casi dos horas volando. Más directos. Haré más directos, Inma.
Danme ideas. Es porque la verdad que mi problema es que no se me ocurren cosas, ¿vale? Así que cualquier cosa que se os ocurra, pues, me lo comentáis.
Miguel Gil, fantástica charla. Gracias. Gracias, Gilberto. Muchas gracias a todos. Si no estáis suscritos, por favor, o suscritas, suscribíos, ¿vale?
Que a partir de los 10.000 puedo hacer stories en YouTube y quiero hacer stories y me quedan todavía 5.000 y algo. Así que a ver si nos suscribimos ahí a saco y puedo hacer stories dentro de poco.
Muchísimas gracias por pasar este ratito conmigo, por acompañarme. Espero que hayáis aprendido algo y nada, de verdad, de corazón, os deseo que estéis bien, que os cuidéis mucho.
Y nos vemos en los siguientes directos para seguir aprendiendo React, Webpack, JavaScript, Frontend, Svelte, cualquier cosa. Así que nada, muchísimas gracias. De verdad, comentad lo que queráis que veamos en los siguientes.
Os mando un abrazo desde todas las partes del mundo que, de verdad, me emociona y todo cuando veo que viene gente de Guatemala, de México, Sudamérica. O sea, me parece increíble. Así que os lo agradezco a todos.
Un abrazo, un abrazo enorme. Un abracito y nos vemos en el siguiente vídeo. Muchas gracias y nada, cuidado mucho, de verdad. Hasta luego. Chao.