typed-typings / env-node Goto Github PK

Currently, fs.Stats is declared as an interface when it is a class.

See documentation

This prevents the usage of obj instanceof fs.Stats (example).

I'd add declaration: true, target: es5 and noImplicitAny: true.

Related to #5.

Looking at the API reference, Error.stackTraceLimit seems to have become the number type.
However, it has been to function in d.ts.
Is this correct?

Makes more sense to group interfaces in their related module.

The type definition file is missing Buffer.alloc, as well as Buffer.allocUnsafe and Buffer.allocUnsafeSlow.

This is documented as a number and Added in: v0.11.8.

Something I've always wanted to do. When writing node programs I really want to disable the default library and just use lib.core.d.ts to avoid bugs that occur from including all of lib.d.ts. However, this isn't possible with the current definitions because console is not part of lib.core.d.ts or node.d.ts.

They disagree about the type of "iterator." The new version of @types/node states that the iterator is "readonly," whereas the most recent version of types for @types/core-js does not say "readonly," resulting in the following error:

504     iterator: symbol;
        ~~~~~~~~

node_modules/@types/core-js/index.d.ts(504,5): error TS2687: All declarations of 'iterator' must have identical modifiers.


50     readonly iterator: symbol;
                ~~~~~~~~

node_modules/@types/node/index.d.ts(50,14): error TS2687: All declarations of 'iterator' must have identical modifiers.

Unfortunately we're targeting Nodejs v4.3 (using AWS Lambda, which hasn't updated their node runtime in a long time and doesn't seem eager to do so soon), so we need some of the polyfills from core-js in order to make our code work.

From https://nodejs.org/api/tty.html#tty_tty:

When Node.js detects that it is being run inside a text terminal ("TTY") context, the process.stdin will, by default, be initialized as an instance of tty.ReadStream and both process.stdout and process.stderr will, by default be instances of tty.WriteStream. The preferred method of determining whether Node.js is being run within a TTY context is to check that the value of the process.stdout.isTTY property is true:

$ node -p -e "Boolean(process.stdout.isTTY)"
true
$ node -p -e "Boolean(process.stdout.isTTY)" | cat
false

It's currently not possible to check process.stdout.isTTY because it is only typed as WritableStream. It should be WritableStream | tty.WriteStream.

The alternative check process.stdout instanceof tty.WriteStream is not possible either, because tty only exports interfaces, not the classes / constructors.

The same applies to process.stdin/tty.ReadStream

The property "secureOptions" is missing in the options of https.createServer (interface ServerOptions)
See: https://nodejs.org/api/tls.html

Mentioned by @felixfbecker.

Node.JS has used a V8 engine which has supported ES2015 Map/Set constructors since 2.0.0 so it would be useful if their definitions could be added to the [email protected] definition.

The definitions themselves can probably be based on the definition in lib.es6.d.ts.

installed: registry:dt/node#6.0.0+20160907103612

current content:

 export interface Process extends EventEmitter {
/// ....
    env: any;
/// ....
}

may change to:

export interface EnvironmentVariables {
    [key: string]: string;
}
export interface Process extends EventEmitter {
/// ....
    env: NodeJS.EnvironmentVariables;
/// ....
}

then users can extend env in their own .d.ts:

declare namespace NodeJS {
    export interface EnvironmentVariables {
        SOME_THING: string;
        SOME_OTHER_THING: string;
    }
}

currently this will cause error TS2403: Subsequent variable declarations must have the same type. Variable 'env' must be of type 'any', but here has type 'IProcessEnv':

interface IProcessEnv {
    SOME_THING: string;
    SOME_OTHER_THING: string;
}
declare namespace NodeJS {
    export interface Process {
        env: IProcessEnv;
    }
}

Hi,
Typescript 1.9 (currently typescript@next) adds definitions for Error.prototype.stack.

It results in a duplicate identifier

C:/Users/Charles/AppData/Roaming/npm/node_modules/typescript/lib/lib.d.ts(883,5): error TS2300: Duplicate identifier 'stack'.
typings/globals/node/index.d.ts(19,3): error TS2300: Duplicate identifier 'stack'.

How do you plan to handle this sort of changes ? Should we remove stack from this definition once TS 1.9 is stable ?

It should not be used, is deprecated and generally creates bugs/fragmentation.

It seems that the typings registry has an old version of these typings. How can these be updated? I see two commits to master since these were last updated. Granted, one was just today, but the other was some days ago.

TAG                   VERSION DESCRIPTION COMPILER LOCATION                                                            UPDATED                 
6.0.0+20161105011511  6.0.0                        github:types/env-node/6.0#088b6275167df0e4bec9bee3205c703253ef4ace  2016-11-05T01:15:11.000Z
4.0.0+20161105011511  4.0.0                        github:types/env-node/4.0#088b6275167df0e4bec9bee3205c703253ef4ace  2016-11-05T01:15:11.000Z
0.12.0+20161105011511 0.12.0                       github:types/env-node/0.12#088b6275167df0e4bec9bee3205c703253ef4ace 2016-11-05T01:15:11.000Z
0.10.0+20161105011511 0.10.0                       github:types/env-node/0.10#088b6275167df0e4bec9bee3205c703253ef4ace 2016-11-05T01:15:11.000Z

The property "connected" was added in Node v0.7.2 according to the 4.x docs.
ChildProcess.connected

This should be added to all of the subsequent versions that need it.

export function readFileSync(filename: string, options: ReadFileOptions): Buffer;
and
export function readFile(filename: string, options: ReadFileOptions, callback: (err: NodeJS.ErrnoException | null, data: Buffer) => void): void;

should be:

export function readFileSync(filename: string, options: ReadFileOptions | null): Buffer;
and
export function readFile(filename: string, options: ReadFileOptions | null, callback: (err: NodeJS.ErrnoException | null, data: Buffer) => void): void;

I can create a PR if desired.

I think the sandbox argument should be any and not Context based on the node documentation.

https://github.com/types/env-node/blob/a5f9e16f769422e801156d494c45453670fc73cc/6.0/node.d.ts#L1202

Currently the examples don't work and I have no idea how to create a context with initial sandbox values other than createContext.

Should I create a PR fixing this or did I misunderstand something?

Definition of WeakMap in newest es6.lib.d.ts:

interface WeakMap<K extends object, V> { }

interface WeakMapConstructor {
    new <K extends object, V>(iterable: Iterable<[K, V]>): WeakMap<K, V>;
}

Definition in Node typings:

interface WeakMap<K, V> extends NodeWeakCollection {
  clear(): void;
  delete(key: K): boolean;
  get(key: K): V | void;
  has(key: K): boolean;
  set(key: K, value?: V): WeakMap<K, V>;
}

interface WeakMapConstructor extends NodeCollectionConstructor<WeakMap<any, any>> {
  new (): WeakMap<any, any>;
  new <K, V>(): WeakMap<K, V>;
}

Error:

typings/globals/node/index.d.ts(108,11): error TS2428: All declarations of 'WeakMap' must have identical type parameters.
typings/globals/node/index.d.ts(118,25): error TS2344: Type 'K' does not satisfy the constraint 'object'.

Should we really define WeakMap in the Node typings if it is clearly part of ES6 spec and should therefor be provided by es6.lib.d.ts?

/cc @blakeembrey

Added in Node 6:
https://nodejs.org/api/url.html#url_url_format_urlobject

Not in Node 5:
https://nodejs.org/docs/latest-v5.x/api/url.html#url_url_format_urlobj

url.format(urlObject)

Added in: v0.1.25
urlObject | A URL object (as returned by url.parse() or constructed otherwise). If a string, it is converted to an object by passing it to url.parse().

There are some missing functions from the util package isBoolean, isNull, _extend and many more.

For better documentation and reuse, for example in vinyl.

It was removed in fd484a5.

fd484a5#diff-454ff0a7aff1da6588b816d269cf7ff9L1605

I've had a polyfill file for noLib support in a few of my projects forever. It'd be amazing to be able to remove them and only rely on this + lib.core.d.ts.

Reference: https://github.com/typings/core/blob/master/custom_typings/node.d.ts.

Been meaning to add for a long time, but been slacking so here's a reference so it's not lost: https://github.com/TypeStrong/ts-node/blob/master/custom_typings/node.d.ts

• Missing module module
• Add missing process args