gruns / ImmortalDB

:nut_and_bolt: A relentless key-value store for the browser.
MIT License
3.05k stars 62 forks source link

Nextjs window is not defined error #63

Open Felipe-martins1 opened 3 years ago

Felipe-martins1 commented 3 years ago

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!😄

gruns commented 3 years ago

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! 🙌

Felipe-martins1 commented 3 years ago

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!

martinschayna commented 3 years ago

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 commented 3 years ago

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

gruns commented 3 years ago

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

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

martinschayna commented 3 years ago

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.

gruns commented 3 years ago

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

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:

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