std signal module does not work on std@0.51.0

[jakobhellermann]

The following code snippet

import {} from "https://deno.land/std@0.51.0/signal/mod.ts";

results in this error:

error: TS2339 [ERROR]: Property 'signal' does not exist on type 'typeof Deno'.
  const streams = signos.map(Deno.signal);
                                  ~~~~~~
    at https://deno.land/std@0.51.0/signal/mod.ts:34:35

TS2345 [ERROR]: Argument of type 'unknown' is not assignable to parameter of type 'AsyncIterableIterator<void>'.
    mux.add(stream);
            ~~~~~~
    at https://deno.land/std@0.51.0/signal/mod.ts:37:13

TS2571 [ERROR]: Object is of type 'unknown'.
      stream.dispose();
      ~~~~~~
    at https://deno.land/std@0.51.0/signal/mod.ts:43:7

Found 3 errors.
``

[nayeemrmn]

You have to use --unstable to access these APIs (for now).

[jakobhellermann]

I see. Would it be possible to show nicer error messages in that case?

[nayeemrmn]

We've implemented unstable by removing symbols from the namespace if the flag isn't given, so not as it is. For built-ins used directly by people the documentation should be enough. For unstable APIs used indirectly via std, that's not the case... we just hope to stabilise anything used in std sooner rather than later.

[ry]

I think the error message is super confusing. We either need to somehow mark std modules as unstable in their URL or provide a better error somehow (reverting 80e2211 would achieve that)

Marking this as a bug.

[notfilippo]

I think a solution could be achieved at compile time. Deno std could include all symbols, stable or not, marking those unstable (for example with a JSDoc comment @unstable). If --unstable flag is not provided and symbols marked unstable are used in code a nice error is shown. This could resolve the issue of a person using an unstable module imported as a URI.

I just don't know if this system is actually easy to implement on the Deno codebase.

[kitsonk]

(reverting 80e2211 would achieve that)

It wouldn't achieve that, it might help enable that. The other option is to not eliminate the unstable APIs when the flag is there, but simply have them be there with a never type, which would make them unusable from a TypeScript perspective, and we could override the message that throws there to give more information and suggest maybe --unstable isn't being used. I will do a POC of that today.

Don't forget #5012 that is meant to cover this issue.

[lucacasonato]

I think the error message is super confusing. We either need to somehow mark std modules as unstable in their URL or provide a better error somehow

@ry That is what #5503 is. It adds a Did you forget to run with '--unstable'? message to TS2339 errors that are caused by unstable properties on the Deno global.

[bartlomieju]

No longer relevant with #5503 landed