Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property 'utime' does not exist on type 'typeof Deno' #5175

Closed
MariusVatasoiu opened this issue May 9, 2020 · 16 comments
Closed

Property 'utime' does not exist on type 'typeof Deno' #5175

MariusVatasoiu opened this issue May 9, 2020 · 16 comments

Comments

@MariusVatasoiu
Copy link

MariusVatasoiu commented May 9, 2020

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

@kitsonk
Copy link
Contributor

kitsonk commented May 9, 2020

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

@MariusVatasoiu
Copy link
Author

MariusVatasoiu commented May 9, 2020

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)?

@kitsonk
Copy link
Contributor

kitsonk commented May 9, 2020

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.

@lucacasonato
Copy link
Member

lucacasonato commented May 9, 2020

@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.

@CarlosOnline
Copy link

CarlosOnline commented May 10, 2020

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

@hayd
Copy link
Contributor

hayd commented May 12, 2020

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.

@itmayziii
Copy link
Contributor

itmayziii commented May 17, 2020

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.

@HoverBaum
Copy link
Contributor

HoverBaum commented May 20, 2020

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.

@Driky
Copy link

Driky commented May 20, 2020

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.

@lucacasonato
Copy link
Member

lucacasonato commented May 20, 2020

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

@Driky
Copy link

Driky commented May 21, 2020

@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 ?

@mickaelvieira
Copy link

mickaelvieira commented May 21, 2020

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

import {
  existsSync,
  readJsonSync,
} from "https://deno.land/std@0.51.0/fs/mod.ts";

@galkowskit
Copy link
Contributor

galkowskit commented May 21, 2020

#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.

@Driky
Copy link

Driky commented May 21, 2020

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

@ferm10n
Copy link

ferm10n commented May 22, 2020

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

@bartlomieju
Copy link
Member

bartlomieju commented Jun 16, 2020

Better docs were added in #5456

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.