deploy_feedback

deploy_feedback copied to clipboard

I expected the following to run:

await Deno.mkdir("example");

But on Deno Deploy I get the following:

TypeError: Deno.mkdir is not a function
    at file:///src/server/index.ts:1:12

Whereas running this locally works fine:

deno run --allow-write server/index.ts

I ran into this because esbuild uses Deno.mkdir: https://deno.land/x/[email protected]/mod.js#L1571-L1574

What made this a bit more confusing was that I also ran into https://github.com/denoland/deploy_feedback/issues/98.

I believe you do not have write permissions on Deno Deploy, as it runs in multiple instances and they would desync one another.

Duplicate of #112 (kinda).

I believe you do not have write permissions on Deno Deploy, as it runs in multiple instances and they would desync one another.

You're right. We want to consider providing "write" abilities in the future, but not anytime soon.

I think it should result in a permission error. Right now the method doesn't exist at all, which makes it not compatible with running Deno locally.

Knowing that it will result in a permission denied, I consider this issue less pressing atm.

Check out the docs, that function is straight up not available in Deno Deploy: https://deno.com/deploy/docs/runtime-fs

I believe it is intentional. You'll need an abstraction that writes those files to a database or object storage likely.

Shouldn't it just be giving a permission error instead of the method missing? Now developers cannot presume any of the Deno method to be available. Libraries should be supporting this next to supporting permission errors.

If libraries should support methods like mkdir missing: those libraries are using Deno for their CI, so this cannot be tested. They should also test for Deno Deploy, which is quite hard to do.

The type of Deno describes a mkdir method always being there (it isn't optional). Therefore the method should just exist in Deno Deploy as well.

Not that I demand this, it's fine to close this issue, but other (library) developers will run into this when their code is run on Deno Deploy, which blocks further adoption.

Ok, if this issue is just what kind of an error should be thrown in this case, then I agree, something consistent would be very helpful.

@bobvanderlinden @justinmchase Expect an update here in the next few days. Deploy's FS is read-only (for now) so if we add these functions they would throw a PermissionDenied.

We rolled the new error in early Feb 2022 as Alon mentioned. Closing the issue as resolved.

PermissionDenied: Requires write access to 'hello', but the file system on Deno Deploy is read-only.
    at Object.mkdir (ext:deno_fs/30_fs.js:148:14)
    at Server.handler (file:///src/main.tsx:10:14)
    at Server.#respond (https://deno.land/[email protected]/http/server.ts:299:37)
    at Server.#serveHttp (https://deno.land/[email protected]/http/server.ts:346:20)
    at eventLoopTick (ext:core/01_core.js:181:11) {
  name: "PermissionDenied"
}