Deno: Property 'utime' does not exist on type 'typeof Deno'

Created on 9 May 2020  路  16Comments  路  Source: denoland/deno

I'm trying the following script and I get a few errors.

index.ts

import { exists } from "https://deno.land/std/fs/mod.ts";

const found = await exists('/folder');
console.log('Found:', found);

Error:

error TS2339: Property 'utime' does not exist on type 'typeof Deno'.
    await Deno.utime(dest, statInfo.atime, statInfo.mtime);
               ~~~~~
    at https://deno.land/std/fs/copy.ts:90:16

error TS2339: Property 'utimeSync' does not exist on type 'typeof Deno'.
    Deno.utimeSync(dest, statInfo.atime, statInfo.mtime);
         ~~~~~~~~~
    at https://deno.land/std/fs/copy.ts:101:10

error TS2339: Property 'symlink' does not exist on type 'typeof Deno'.
  await Deno.symlink(originSrcFilePath, dest, type);
             ~~~~~~~
    at https://deno.land/std/fs/copy.ts:114:14

error TS2339: Property 'utime' does not exist on type 'typeof Deno'.
    await Deno.utime(dest, statInfo.atime, statInfo.mtime);
               ~~~~~
    at https://deno.land/std/fs/copy.ts:119:16

error TS2339: Property 'symlinkSync' does not exist on type 'typeof Deno'.
  Deno.symlinkSync(originSrcFilePath, dest, type);
       ~~~~~~~~~~~
    at https://deno.land/std/fs/copy.ts:132:8

error TS2339: Property 'utimeSync' does not exist on type 'typeof Deno'.
    Deno.utimeSync(dest, statInfo.atime, statInfo.mtime);
         ~~~~~~~~~
    at https://deno.land/std/fs/copy.ts:137:10

error TS2339: Property 'utime' does not exist on type 'typeof Deno'.
    await Deno.utime(dest, srcStatInfo.atime, srcStatInfo.mtime);
               ~~~~~
    at https://deno.land/std/fs/copy.ts:157:16

error TS2339: Property 'utimeSync' does not exist on type 'typeof Deno'.
    Deno.utimeSync(dest, srcStatInfo.atime, srcStatInfo.mtime);
         ~~~~~~~~~
    at https://deno.land/std/fs/copy.ts:185:10

error TS2339: Property 'link' does not exist on type 'typeof Deno'.
  await Deno.link(src, dest);
             ~~~~
    at https://deno.land/std/fs/ensure_link.ts:28:14

error TS2339: Property 'linkSync' does not exist on type 'typeof Deno'.
  Deno.linkSync(src, dest);
       ~~~~~~~~
    at https://deno.land/std/fs/ensure_link.ts:52:8

error TS2339: Property 'symlink' does not exist on type 'typeof Deno'.
  await Deno.symlink(src, dest, srcFilePathType);
             ~~~~~~~
    at https://deno.land/std/fs/ensure_symlink.ts:31:14

error TS2339: Property 'symlinkSync' does not exist on type 'typeof Deno'.
  Deno.symlinkSync(src, dest, srcFilePathType);
       ~~~~~~~~~~~
    at https://deno.land/std/fs/ensure_symlink.ts:58:8

Found 12 errors.

deno 1.0.0-rc1
v8 8.2.308
typescript 3.8.3

Most helpful comment

It is not ideal that some modules in std require --unstable (especially mod.ts files).

Perhaps it makes sense to separate/group path/mod.ts and path/unstable.ts?

At the moment if I want to use path.join, I'm out of luck, even though it doesn't - as far as I can tell - itself use an unstable api. That doesn't really make sense.

All 16 comments

These features are now under the --unstable flag... To enable them, deno run --unstable.

You're right, it works with the --unstable flag.
Now I'm wondering if there should be thrown a PermissionDenied error (similar with other flags)?

It is hard to detect, in TypeScript, that you are trying to access an API that is considered unstable... they simply don't exist, though obviously the TypeScript errors are confusing.

@lucacasonato @ry I think people are going to keep getting tripped up by this. I wonder if when running without the --unstable flag we tried to "trap" these diagnostics and potentially rewrite the message to indicate that --unstable flag could be used... It would likely require maintaining a static list of APIs names we would build into the compiler.

@kitsonk While having to keep a list in the compiler is not great, it would be the best end user experience, so I think it's a good idea.

Please update README to specify deno run --unstable is required.

It is not ideal that some modules in std require --unstable (especially mod.ts files).

Perhaps it makes sense to separate/group path/mod.ts and path/unstable.ts?

At the moment if I want to use path.join, I'm out of luck, even though it doesn't - as far as I can tell - itself use an unstable api. That doesn't really make sense.

For now I'm resorting to importing files directly like import { readFileStr } from 'https://deno.land/std/fs/read_file_str.ts';. Not ideal, but getting warnings/errors when importing from a mod.ts file seems like unexpected behavior.

Ran into the same issue today. Using --unstable changed the errors I got but what fixed the errors in the end was pinning the version to something explicit.

However I would also opt to using specific imports for now so that users do not have to use the --unstable flag.

After running with the --unstable flag I get the following:

error: TS2345 [ERROR]: Argument of type '{ type: string; }' is not assignable to parameter of type 'string'.
    await Deno.symlink(originSrcFilePath, dest, {

    at https://raw.githubusercontent.com/denoland/deno/master/std/fs/copy.ts:117:49

TS2345 [ERROR]: Argument of type '{ type: string; }' is not assignable to parameter of type 'string'.
    Deno.symlinkSync(originSrcFilePath, dest, {

    at https://raw.githubusercontent.com/denoland/deno/master/std/fs/copy.ts:141:47

TS2345 [ERROR]: Argument of type '{ type: string; }' is not assignable to parameter of type 'string'.
    await Deno.symlink(src, dest, {

    at https://raw.githubusercontent.com/denoland/deno/master/std/fs/ensure_symlink.ts:33:35

TS2345 [ERROR]: Argument of type '{ type: string; }' is not assignable to parameter of type 'string'.
    Deno.symlinkSync(src, dest, {

    at https://raw.githubusercontent.com/denoland/deno/master/std/fs/ensure_symlink.ts:65:33

Found 4 errors.

It seems like a really bad use experience to have Deno in v1.0.0 and still have part of the std under an unstable flag and getting errors even with that flag. I'm not trying to be mean but it's a critical time for Deno to make a good impression on users.

@Driky Lock your imports to a specific version rather than implicitly relying on the master branch.

@lucacasonato thank you for the tips.

Importing like this:

import {
  existsSync,
  readJsonSync,
} from "https://raw.githubusercontent.com/denoland/deno/v1.0.0-rc2/std/fs/mod.ts";

get me the following:

error: TS2322 [ERROR]: Type 'string' is not assignable to type 'boolean'.
  return srcArray.reduce(

    at https://raw.githubusercontent.com/denoland/deno/v1.0.0-rc2/std/fs/_util.ts:20:3

any specific tag someone would recommend I target ?

@Driky I believe you need to specify the standard library's version like this:

import {
  existsSync,
  readJsonSync,
} from "https://deno.land/[email protected]/fs/mod.ts";

https://github.com/denoland/deno/issues/5630 <- there was a similar issue.

I think there are two main culprits here:

  1. Having to use --unstable in std packages is weird. I dislike that behaviour with passion.
  2. Documentation pages like this one https://deno.land/std/fs use untagged versions in examples.

@mickaelvieira thank you I'll test that
EDIT: that works

What if we made the missing --unstable flag cause a runtime error instead of at compile time? Would that be better?

I had an idea on how to implement that, link here... I might have posted it in the wrong place though. Basically what it would do is throw an error if you try to use an unstable API without the unstable flag.

What's nice about it is that you don't need to maintain a list of unstable API names, and it also doesn't require trapping the diagnostic messages and doing a string search and replace

Better docs were added in https://github.com/denoland/deno/pull/5456

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ry picture ry  路  3Comments

kitsonk picture kitsonk  路  3Comments

kyeotic picture kyeotic  路  3Comments

ry picture ry  路  3Comments

ry picture ry  路  3Comments