third party library, lazy loading, dev server complains, static build is fine

[yacoob]

tl;dr: I get a dynamic component resolution problem in dev server only despite lazy loading and I can't figure out why.

I'm making a nuxt version of my website. I want to continue using lightgallery for the images. It has an official vue wrapper, but only for vue3. Regardless of the vue version, that library accesses window during import, and as such causes problems with ssr enabled. The author admits as much, and recommends dynamic loading (eg. here).

Now, I wrote my own simple vue 2 component for lightgallery. I've wrapped the instantiation of that component in <client-only> and prefixed the name of the component with lazy as seen here. To my surprise, this still resulted in following error produced on both the terminal and browser's console when I visited a page using that component on the dev server:

20:17:56.265 [Vue warn]: Failed to resolve async component: () => __webpack_require__.e(/*! import() | components/gallery-controller */ "components/gallery-controller").then(__webpack_require__.bind(null, /*! ../../components/GalleryController.vue */ "./components/GalleryController.vue")).then(c => Object(_utils__WEBPACK_IMPORTED_MODULE_1__["wrapFunctional"])(c.default || c))
Reason: ReferenceError: window is not defined client.js:56
    NuxtJS 11
        <anonymous>
        <anonymous>
        <anonymous>
        js
        __webpack_require__
        fn
        0
        __webpack_require__
        checkDeferredModules
        webpackJsonpCallback
        <anonymous>

The gallery works more or less fine from what I can tell, despite this error. I had some hiccups when I initially wrote this question, but I think I can chalk it up to browser misbehaving on my end. What's most perplexing to me, the site works fine once generated for static serving - that is, yarn generate. This fact really makes me think this tickles some weird bug in nuxt that is specific to the dev server.

My project's code at the version displaying this behaviour is here and here is a matching netlify build. I don't have any experience with modern webdev and webpack - so tracing this down takes a lot of time and effort. I'd be grateful for some sort of diagnosis here :D

Thanks!

[yacoob]

Some observations from shotgun debugging of this:

• The resolve error only happens if I do a full page load of a page that contains this wrapper component. If I load a different page first, then navigate to a page with that component, no error happens.
• The error goes away on the dev server if I set ssr: false in the config file. To my surprise, that toggle affects output of yarn generate too - with ssr: false the generated dist/ directory contained a large blob of all data from content/ which would be used for generating pages ad-hoc, as long as I move within links generated by nuxt-link. I guess here goes my lack of experience with spa/ssr etc. :) I honestly believed that ssr and ssg are two exclusive options in nuxt world. I don't want to set ssr: false for my production build though, to make sure crawlers see the content without having to run the JS.
• as an experiment, I moved import of all lightgallery files (js and css) into a client-side plugin. This gave me working lightgallery and no error message - but at the cost of having lightgallery code present on every single page. Which makes sense, it's injected in the context, so technically speaking should be "available" on every page. I don't want to do that, to keep the page size down. :)

I'd really like to understand where does the error come from in ssr: true dev server scenario. Plus, why does the gallery work regardless of this issue. There's no stack trace on the console, and the stack trace from the client suggests this error happens on the client side. Which should leave things broken - except it doesn't.

Really puzzled by this :)

[manniL]

This likely happens because the LightGallery component is using window during the import of it already (outside of it's export default block). [Further read](
Further read: https://deltener.com/blog/common-problems-with-the-nuxt-client-only-component/)

One option, as you already discovered, would be using a client-side plugin.

Another option would be adding a wrapper (as you did) which lazy-loads the LightGallery component and then Wrapping a <ClientOnly> around that wrapper! This seems twice the work but ensures that no window is being used on the server-side.

I actually did sth. similar in a project using vue-gallery:

GalleryWrapper.vue

<template>
  <Gallery :images="images" :index="index" @close="$emit('close')" />
</template>

<script>
export default {
  components: {
    Gallery: () => import('vue-gallery/src/component/gallery.vue')
  },
  props: {
    images: {
      type: Array,
      required: true
    },
    index: {
      type: Number,
      required: true
    }
  }
}
</script>

On the page, say photos.vue:

<template>
  <ClientOnly>
    <GalleryWrapper :images="images" :index="index" @close="index = null" />
  </ClientOnly>
</template>

---

Hope that helps!

[yacoob]

All of the code that calls the gallery script is in callbacks that shouldn't be used serverside - which suggests that the code that references window runs as a side effect of the import statement. Is there any way for me to verify this?

What I still don't understand is why the code of my wrapper is being executed (analysed?) at all, if I lazy load it. I thought this was the method to make sure the server side will ignore it (in combination with wrapping the instantiation in <client-only>). In other words - <client-only> precludes it from rendering on the server side, dynamic loading makes sure it doesn't get analysed as dependency. Am I getting this wrong? I just don't understand why the code of my GalleryController gets executed at all on the server-side in the current shape. As it stands, I'm doing exactly what the article you've linked earlier suggests - and it still fails, producing a working website and messed dev server :D

FWIW, I was experimenting with gridsome some time back, and lazy loading my wrapper and marking the component instantiation as client only was sufficient to make things work. Both gridsome and nuxt use vue server renderer under the hood AFAIK, so I think the problem I'm seeing here is not related to ssr per se - but rather to the way webpack is configured for nuxt's dev server. I severely lack experience and knowledge to debug that though. :) What's important here I guess is that the problem happens only with the dev server, and doesn't show up during static site generation - which heavily suggests there's something specific to the nuxt dev server that trips it up.

[manniL]

All of the code that calls the gallery script is in callbacks that shouldn't be used serverside - which suggests that the code that references window runs as a side effect of the import statement. Is there any way for me to verify this?

Yes, check out what the imported library is doing ☺️

What I still don't understand is why the code of my wrapper is being executed (analysed?) at all, if I lazy load it. I thought this was the method to make sure the server side will ignore it (in combination with wrapping the instantiation in <client-only>). In other words - <client-only> precludes it from rendering on the server side, dynamic loading makes sure it doesn't get analysed as dependency. Am I getting this wrong? I just don't understand why the code of my GalleryController gets executed at all on the server-side in the current shape. As it stands, I'm doing exactly what the article you've linked earlier suggests - and it still fails, producing a working website and messed dev server :D

Because the component is not rendered on the server-side but it's code is still read and executed. That means all window usage in the Vue component itself (inside the export default object, e.g. in methods or lifecycle hooks) are not triggered (because the component is not rendered) but the code before is interpreted because the component will still be executed.

[yacoob]

I've made a minimal reproduction case here. It has a nuxt project created via yarn create nuxt-app, an "external" js library under ~/vendor, and a wrapper for it at ~/components/Wrapper.vue. That wrapper is lazy loaded in ~/pages/index.vue and used inside <client-only> tag.

At this commit the third party library loads fine and works as expected. At this commit I make it use window.alert outside of the export block, and I get the error similar to the one I've initially described in this thread:

 ERROR  [Vue warn]: Failed to resolve async component: () => __webpack_require__.e(/*! import() | components/wrapper */ "components/wrapper").then(__webpack_require__.bind(null, /*! ../../components/Wrapper.vue */ "./components/Wrapper.vue")).then(c => Object(_utils__WEBPACK_IMPORTED_MODULE_1__["wrapFunctional"])(c.default || c))
Reason: ReferenceError: window is not defined

This error:

• does not prevent the library from working (displaying two pop ups)
• is not present in the static site generated from this project
• happens only when running the dev server
• shouldn't happen if the wrapper is lazy loaded, according to your explanations and the linked article

[yacoob]

Posted my last update just before I've looked at the notification about your comment :)

(...) is not rendered on the server-side but it's code is still read and executed.

I thought that this is exactly what lazy loading was supposed to prevent? What is executing that code and for what purpose, if all of its usage is explicitly marked as client-side?

[yacoob]

Interesting development: my minimal reproduction case behaves differently with nuxt 2.15.8. Specifically - it still works without any problems in the static site generated from the project but with the dev server it now displays a proper error page:

I've looked at the diff between 2.15.7 and 2.15.8 and it's really tiny but I don't really have a good clue what could have caused this beahviour change. @manniL any idea what is happening here?

I'm slowly leaning towards reopening this as a bug, given that it only happens in the dev server. :(