Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

204
Vistas
What if I want to make a shared library out of ES modules?

from some test I just did, it seems that if I import some modules in a say, dependencies.js file, without tree shaking, and then load it in page, and after it load another js file in page, that wants to use modules from dependencies.js, it won't work because it seems modules scoped to dependencies.js and not available outside. Is it correct? And if I want, is there a way to 'solve' this problem?

about 4 years ago · Juan Pablo Isaza
2 Respuestas
Responde la pregunta

0

Yes, you re-export them from dependencies.js. For instance:

// dependencies.js
export { something } from "./something.js";
export { somethingElse } from "./something-else.js";

Note that they will only be re-exported, they won't be available to code in dependencies.js. If you want to use something / somethingElse in dependencies.js, import them, then re-export them:

// dependencies.js
import { something } from "./something.js";
import { somethingElse } from "./something-else.js";

export { something, somethingElse }; // Or export them individually

Either way, those exports will be available to anything consuming them from dependencies.js. But note that they'll also be available directly from something.js and something-else.js. (And either way, they're all bindings to the same exports.)

about 4 years ago · Juan Pablo Isaza Denunciar

0

Ok, adding my own answer here. So, to resume:

  • Needed a way to load a shared.js file on all website pages, with all the shared libraries inside (things like Swiper, Fancybox, etc, which you want to be in cache and do not want to reload separetely or bundled on each page).

  • Needed those libraries to be available to other js files and modules that are loaded in page after shared.js

  • Needed to use es modules

  • Needed to use bundlers (rollup in my case, or webpack)

Problem # 1

Modules scope is only the js files where they're defined or imported.

Problem # 2

By exporting modules and importing them in other module files:

  • if we do not use bundlers, there will be performance issues (in other words, even if es modules are currently supported by all major browsers, it's not really recommended to use them raw > instead, we still need budlers > there are articles about this on the web).

  • if we use bundlers, when importing libraries they will be added to the main file. Therefore, in this case, we would end up loading a copy of Swiper & co on each page.

Solution #1 (the fast and dirty)

In one sentence: on shared.js, import the modules and then add them to the global scope, the old school way: window.Swiper = Swiper.

Or, if you're really afraid of global variables (which have been used for 20 years now all over the web without destroying it, luckily...), on shared.js just export them, and by budling the file, you'll end up with the libraries on a sort 'namespaced' global scope. The budler will create one single variable (just look at the source of the budled file), which will serve as the access to the libs. Something like shared.Swiper. Whish just means window.shared.Swiper

Solution #2 (the 'modern' one)

Code splitting. All the main bundlers can do it in various ways, so just check docs from Webpack, Parcel, Rollup or Laravel mix.

about 4 years ago · Juan Pablo Isaza Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda