ImmortalDB icon indicating copy to clipboard operation
ImmortalDB copied to clipboard

Nextjs window is not defined error

Open Felipe-martins1 opened this issue 4 years ago • 7 comments

Hi!

i'm recently working on the nextjs project and i started using immortalDB, but i'm getting the error "window not defined", even before using any of the functions (get, set, delete), when i import immortalDB the error starts to show up, how can i fix this? thanks!

Good job, ImmortalDB is awesome!😄

Felipe-martins1 avatar Jun 22 '21 13:06 Felipe-martins1

  1. is this with the latest ImmortalDB v1.1.0?

  2. please provide minimal code to reproduce the error so i can see exactly what you see

these window checks may not suffice https://github.com/gruns/ImmortalDB/blob/master/src/index.js#L23, but i cant tell without an example where i can attempt to reproduce your error(s)

alternatively, can you test and open a pull request that fixes this? ideally the fix is simple, like the above WINDOW_IS_DEFINED variable

thank you! 🙌

gruns avatar Jun 22 '21 15:06 gruns

Hey! Yes, is the latest version. basicaly, to reproduce the error, you should create a nextjs project and install ImmortalDB, after this, when you import ImmortalDB, the error comes up.

I'll try to solve this and make a pull request, thanks!

Felipe-martins1 avatar Jun 23 '21 20:06 Felipe-martins1

The same in my project, when I've installed the immortal-db package and put import { ImmortalDB } from "immortal-db" somewhere in the source code (even the import is not in use), then mocha tests running in nodejs are failing on this error.

martinschayna avatar Sep 03 '21 10:09 martinschayna

mocha tests running in nodejs are failing on this error.

It is failing on this line: https://github.com/gruns/ImmortalDB/blob/master/dist/immortal-db.js#L10

Obviously, the bundle was not bundled for node target. Is it possible to distribute bundle for node target too? Maybe via multiple targets defined in webpack config, see: https://webpack.js.org/concepts/targets/#multiple-targets

martinschayna avatar Sep 03 '21 11:09 martinschayna

ya. we'll likely have to build two targets, a la

  • https://levelup.gitconnected.com/how-to-bundle-your-library-for-both-nodejs-and-browser-with-webpack-3584ec8197eb

but @Felipe-martins1 and @martinschayna as we walk down this path together, help me understand: how/why is immortaldb being imported and used in node? for example, as part of the build process? or do you actually run immortaldb in node with browser shims?

perhaps there's another solution here before we build two targets: one for node and one for the browser

gruns avatar Sep 03 '21 19:09 gruns

how/why is immortaldb being imported and used in node?

The reason in my case is unit testing in mocha, which is running in node. Some low level parts of my web application uses immortal-db for caching, mainly for outstandingly simple interface and very usable configuration. These parts are used from the web app, so I want to test them carefully. Other people may use immortal-db on server side, which is also running in node.

martinschayna avatar Sep 07 '21 08:09 martinschayna

The reason in my case is unit testing in mocha, which is running in node.

makes sense. thank you for sharing!

from my limited knowledge of webpack, and going off of

  • https://levelup.gitconnected.com/how-to-bundle-your-library-for-both-nodejs-and-browser-with-webpack-3584ec8197eb

it looks like two different build versions would be necessary

that said, zooming out, building for node really doesnt make much sense as all the storage engines that immortaldb uses don't exist in node, ie:

  • cookies
  • indexeddb
  • localstorage

so while a version of immortaldb can certainly be built for node -- one that doesn't use the global window variable, immortaldb wouldnt actually do anything as none of the storage engines exist in node without polyfills

this would, in turn, render all immortaldb usage no-ops in node

gruns avatar Sep 10 '21 18:09 gruns