localStorage API errors for compiled deno binaries

[grempe]

I was excited to try out the new localStorage API (which seems like a great and natural fit for CLI's) and I found that it throws an error for any compiled output. This was run with Deno 1.10.2 on macOS.

welcome.ts

console.log("Welcome to Deno!")

localStorage.setItem("foo", "bar")
console.log(localStorage.getItem("foo"))
console.log(localStorage.length)

output : uncompiled

❯ deno run --location=https://127.0.0.1 welcome.ts
Welcome to Deno!
bar
1

output : compiled

❯ deno compile --unstable --location=https://127.0.0.1 welcome.ts
Check file:///private/tmp/cli/welcome.ts
Bundle file:///private/tmp/cli/welcome.ts
Compile file:///private/tmp/cli/welcome.ts
Emit welcome

❯ ./welcome
Welcome to Deno!
error: NotSupported: LocalStorage is not supported in this context.
    at DOMExceptionNotSupportedError (deno:runtime/js/99_main.js:199:16)
    at unwrapOpResult (deno:core/core.js:106:13)
    at Object.opSync (deno:core/core.js:120:12)
    at createStorage (deno:extensions/webstorage/01_webstorage.js:93:22)
    at localStorage (deno:extensions/webstorage/01_webstorage.js:178:24)
    at file://$deno$/bundle.js:2:1

The error message seems to originate from here:

deno/extensions/webstorage/lib.rs

Line 70 in dfe5281

"LocalStorage is not supported in this context.",

[crowlKats]

The problem is that we currently lack DENO_DIR in compiled context, which is required to store the SQLite file backing localStorage. This is definitively something wanted, but was omitted for the first iteration

[imjamesb]

@ry Wasn't this the intended behaviour, making it not a bug?

deno/extensions/webstorage/lib.rs

Lines 68 to 72 in 19e4080

	let path = state.try_borrow::<LocationDataDir>().ok_or_else(|| {
	DomExceptionNotSupportedError::new(
	"LocalStorage is not supported in this context.",
	)
	})?;

[kitsonk]

bug/feature, minor distinction, but I changed the label

[grempe]

Thanks. I would suggest that the docs page reflect this (current) limitation.

Does it have to write to DENO_DIR? What about using arch specific default locations?

e.g.

https://deno.land/x/config_dir@v0.1.1/mod.ts

[wiremoons]

Out of interest - I don't understand the logic of this issue being labelled as a feature and not a bug?

The reason for thinking it is in fact a bug is that Deno is 'broken' functionality wise for any script that uses LocalStorage and wants to use the compile option. Both are great existing capabilities in Deno, so the fact they don't work together correctly is not intended behaviour - or is it?

I don't think any developer would (or should) purposefully break a program capability, and then label the outcome a feature?

But whichever is fine - I guess my real interest is when it might be fixed or the feature added :)

Don't take my questions the wrong way please - I know there are lots of other higher priority issues, so I am not complaining, just checking out of interest. Also it is quite an amusing label switch from a user perspective for the reason outlined above :)

[crowlKats]

The reason this is a feature is because this requires adding some sort of caching capability to compiled as localStorage requires to store a sqlite file on the disk. its not a bug as this was fairly intentional when localStorage was merged, and as such isnt unexpected behaviour

[pitkes22]

Please mention this in the documentation page of Compiling Executables.

[maekoos]

I'm interested in getting this to work. Would it be a bad idea to require the user to supply the origin_data_folder_path manually during compilation? Maybe by using a flag like --origin-data=./data?

[libewa]

Maybe, at least on Linux/macOS, the data directory could be $XDG_DATA_HOME/deno/appname/, $HOME/.local/share/deno/appname/ (which is the same folder by default) or something like that.
Windows provides a clear solution in the form of AppData folders (and all applications that save config data in Documents are annoying).