Es una situación IIFE muy simple en JavaScript.
Pero el punto y coma al final de la primera línea marcará una gran diferencia, ya sea que esté allí o no.
Aquí está la versión de error y sin punto y coma en la primera línea:
const obj = {} (function () { })()Y Chrome se queja de que:
Uncaught TypeError: {} is not a function¿Cómo lee el navegador este código?
Si agregamos un punto y coma al final de esa línea, el error se descarta:
const obj = {}; (function () { })()Me dijeron que el punto y coma no es necesario en JavaScript, pero aparentemente está mal en esta situación. ¿Por qué?
Los puntos y coma en JavaScript son opcionales, pero a veces la falta de un punto y coma puede producir un error.
En su caso, el const obj = {} puede estar en varias líneas y seguir:
const obj = { } Entonces, javascript en realidad no sabe cuándo finalizó o no su declaración de ejecución. Como resultado, javascript considera const obj = {} (function() {})() como una declaración única, lo que produce un error.
Mientras que, cuando coloca un punto y coma, especifica explícitamente que la declaración terminó aquí, por lo tanto, const obj = {} y (function() {})() como declaraciones separadas.
Esto también se discute en https://eslint.org/docs/rules/semi
De la especificación del lenguaje ECMAScript®:
12.9.3.1 Casos interesantes de inserción automática de punto y coma en listas de extractos
En una StatementList , muchos StatementListItems terminan en punto y coma, que pueden omitirse mediante la inserción automática de punto y coma. Como consecuencia de las reglas anteriores, al final de una línea que termina una expresión, se requiere un punto y coma si la siguiente línea comienza con cualquiera de los siguientes:
Un paréntesis de apertura ((). Sin un punto y coma, las dos líneas juntas se tratan como CallExpression .
Un corchete de apertura ([). Sin un punto y coma, las dos líneas juntas se tratan como acceso de propiedad, en lugar de ArrayLiteral o ArrayAssignmentPattern .
Un literal de plantilla (`). Sin un punto y coma, las dos líneas juntas se interpretan como una Plantilla etiquetada (13.3.11), con la expresión anterior como MemberExpression .
Unario + o - . Sin un punto y coma, las dos líneas juntas se interpretan como un uso del operador binario correspondiente.
Un literal RegExp . Sin un punto y coma, las dos líneas juntas pueden analizarse como / MultiplicativeOperator , por ejemplo, si RegExp tiene banderas.