typed-typings / env-node Goto Github PK
View Code? Open in Web Editor NEWTypings for Node.js
Typings for Node.js
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().
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.
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 "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.
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.
It was removed in fd484a5.
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
.
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?
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.
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).
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.
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
typings/main/ambient/node/index.d.ts(69,3): error TS7010: 'stackTraceLimit', which lacks return-type annotation, implicitly has an 'any' return type.
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
module
moduleprocess
argsHi,
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 ?
There are some missing functions from the util package isBoolean
, isNull
, _extend
and many more.
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?
The property "secureOptions" is missing in the options of https.createServer (interface ServerOptions)
See: https://nodejs.org/api/tls.html
The type definition file is missing Buffer.alloc
, as well as Buffer.allocUnsafe
and Buffer.allocUnsafeSlow
.
It should not be used, is deprecated and generally creates bugs/fragmentation.
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
I'd add declaration: true
, target: es5
and noImplicitAny: true
.
Related to #5.
For better documentation and reuse, for example in vinyl.
This is documented as a number and Added in: v0.11.8.
Makes more sense to group interfaces in their related module.
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;
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.