Giter Site home page Giter Site logo

discussions's People

Contributors

blakeembrey avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

discussions's Issues

Exposing API docs

Hi there,

I was just thinking ... wouldn't it be an idea to typedoc each registered definition, and add that information to the (yet to be completed) registry? That way, developers can quickly look up the type signature of a function, and see which (sometimes hidden) type names are used.

Don't understand globals, dt~css must be installed as global but shouldn't according to FAQ

The faq says -

Global dependencies are type definitions that are global or otherwise provide information about the environment. Some examples of "environment" dependencies are Node.js, Browserify, window and even Array.prototype.map. These are globals that exist at runtime, you do not "require" them.

I am using the css module from npm and try to install typings using typings install dt~css, the logic being that according to the faq, since i need to require (or import) the module in order to use it, then it is not a global.

However i get the error.

Attempted to compile "css" as an external module, but it looks like a global module. You'll need to enable the global option to continue.

This doesn't make any sense to me.

Declaring a global variable

Hello,

I am currently writing a typing for WebdriverIO.

WebdriverIO has two modes, standalone and wdio test runner based on mocha.

In standalone mode client is responsible for initializing and closing browser session and more over in standalone mode API works synchronously.

In wdio mode test runner will initialize and clean up browser object and API works asynchronously. This browser object available globally when run via test runner.

I have a working code for the standalone mode. My question is what can be done to make this global browser object available from typescript library.

I am seeing examples to make global module but not sure whether this is the best way to do it?

Thanks in advance.

Regards,

Farhan

Are multiple versions for a given typing planned?

I will clarify my question: Looking through the registry, I could not find typings that did not point to a single version of a given library's typings. Let's take redux-thunk as an example, right now it's pointing to typings for version 1.0.4. When/if redux-thunk releases a version 1.0.5 or 2.0.0, is there plan to simply add this version and keep the old version so it becomes possible to download either versions of the typings, depending on which one is used in a given project?

I feel like that is the plan, but I would like to confirm since that's something that did stop me from using TypeScript in the past, the way DefinitelyTyped handled versioning of typpings and how convoluted that repository became.

Adding a new repository under the typed-typings organization

I've been working locally with slightly tweaked DT definition files for React and Flux to un-globalize them and would like to add them to the registry. Good information I'm following in the registry README, but didn't quite catch the process to add the typings under the typed-typings namespace.

Best practices for npm module typing?

So I recently started using Typescript and of course I want to use my own packages with it and include the typings files inside the npm package itself.

My npm package is designed where the root entry point points to a "class" that you use new on to create a new instance of said class.

const SmartBuffer = require('smart-buffer');
let buff = new SmartBuffer();

What I struggled with was how to properly write the definitions files for it. Do I need to wrap it in a module? Just export declare a class? Eventually I got it to where I can import with typescript like this:

import SmartBuffer = require('smart-buffer');
let buff = new SmartBuffer();

And vscode/webstorm etc all have intellisense for the instance buff.

I just wanted to make sure this is the proper way to write the definition files in this particular instance:

https://github.com/JoshGlazebrook/smart-buffer

(there is only one .d.ts file so it shouldn't be too much of a pain to look through)

Namespace hack

Let's not merge namespace hacks so people can use "ES6-style imports" with CommonJS code. Remember to point out when someone is using an import incorrectly. I'm adding this issue mostly as a bookmark for future reference, since I commonly write something up like typed-typings/npm-basic-auth#1 (comment). There's a good answer on Stack Overflow by Ryan we can point people to now - https://stackoverflow.com/questions/39415661/why-cant-i-import-a-class-or-function-with-import-as-x-from-y 👍

typings file structure best practices

Originally I tend to organize typings in multiple files so that they are more manageable. e.g. npm-chai.

But now through the conversation in UMD, and best practice of exposing types, it seems like it is actually best to keep them in 1 file (or 2, if we can't nicely solve the UMD issue microsoft/TypeScript#7125 and microsoft/TypeScript#7156)

The key statement is this:
"how would it look like if the package is actually written in TypeScript and compiled using tsc -d"?
It has the following benefits:

  • Non-argumentative
  • Simple to define, simple to follow
  • No need to think about folder structure (lib or src? Nested or mirror source structure?)
  • The .d.ts file can easily be moved into the source package when package author agrees

Relevant discussions:
typings/typings#402
typings/typings#10
typings/typings#354

Typing badges

I was thinking of creating a website for badges, in the spirit of sites like http://david-dm.com, for providing badges that inform the user whether the package has typings associated with it. This would promote the creation of typings for packages. Sounds like a good idea? If so, I'd be able to work on it this summer holiday.

Preparing a set of independent typings

I have a framework library written in javascript.
https://github.com/webgme/webgme
The documentation looks reasonable.
https://editor.webgme.org/docs/source/PluginBase.html

As a first step in prepaing to use typing, I made a typing project and filled in a few interfaces by hand.
https://github.com/phreed/npm-webgme
I have a project that uses the webgme library.
https://github.com/phreed/webgme-immortals
That is being converted to use TypeScript.

Include the typing descriptions that are in phreed/npm-webgme into phreed/webgme-immortals.

typings install webgme=github:phreed/npm-webgm

How do I configure a project including the type definitions, to be used by a typescript project?

How to add new typings

Hi I'd like to colaborate with some typings I'm using and I'd like to understand the best way to do it.

Let's say for instance Immutable-js. The project already have the d.ts file, so I don't have to create it. Should I create a repository on github for the typings.json? Or would it be better to add the file to their repository?

Also, in that case, what's the difference between the main and the browser properties for the typings.json?

Finally, in the example used in the docs for the debug.json version file, there's a hash there, I could no find a commit related to that hash? From where that hash came?

Thanks

Website Design

It'd be nice to have a typings website that can point people to getting started and searching and reading about how to write typings and use TypeScript.

Some resources:

What is "env" source?

Can you please explain this a bit more?
For example I run typings search node and results show me that node available as "env" source.
What does that mean? And how to install node from "env" source?
I've tried typings install env:node (ha-ha) without success.

Project and eco-system migration to a post Typescript 2.0 world

I have a handful of type definitions (some converted from DT) that embrace the use of external modules that was a huge selling point when typings got started. I'm starting a new project and this is my first opportunity to get in sync with Typings 2.0's support for installing type definitions. I spent a fair amount of time getting caught up on everything, but everything is still a bit disjointed. I got some questions/musings:

  • Microsoft docs suggest installation via something like npm install @types/react, which pulls a migrated definition from the old DefinetlyTyped. With typings, typings/registry was the preferred repo.
    • I feel like this is a step backwards to potentially using deprecated type definitions.
    • What steps do I need to take to ensure a type definition from typings/registry takes precedence over what @types is using? Especially considering that a handful of PR's to fix/update some definitions only had the registry definitions in mind - not those in DefinetlyTyped
  • Are there caveats to installing from typings/registry with Typescript 2? Btw, how would I do that now?
  • What exactly is the use case for Typings and the registry now? Should I continue maintaining here?

I'm very patient and excited to see this all become 'standardized' in a way; I have no strong opinions and am along for the ride :) but, it's always been a bit painful. Thanks for any thoughts.

Global Typings - can / should I add them to npm package?

I've published an npm package: angular-cc-appinsights.

The package is targeting front-end angular 1 developers and will therefore be loaded as a script tag from the the locally installed node_modules directory.

The package is written in typescript and compiled to JavaScript with declaration files.

Reading the examples of how to publish my typings, I seem to fall into both example 2 and 5.

I have gone with option 5: include in the npm package the compiled JS and declaration files.

I suspect packaging global typings might be wrong...

At first blush, this seems to be the right thing to do. Certainly when I go and install my package into an angular application written in typescript the typescript language service picks up my typings from the npm package.

However, I have a nagging feeling I'm not doing things correctly or at least not in keeping with the spirit of the typings project.

My doubts are two fold:

1. I had to manually amend the d.ts file produced to include:

declare module "angular-cc-appinsights" {
    import appinsights = cc.appinsights;
    export = appinsights;
}

2. My definitions expose dependencies from the angular (1) typings installed from definitely typed.

This I believe is a problem as I should somehow be describing which specific version of angular typings I'm depending on

Can you guys point me to the correct approach?

Thanks
Christian

Best way to export interfaces for a module that only has a default export

This is more a question about writing type definitions than about typings, feel free to let me know if I should post this elsewhere!

I've been working on the type definitions for Griddle, which only exports a React class, essentially to be used like so:

import * as React from 'react';
import { render } from 'react-dom';
import Griddle from 'griddle-react';

render(
  <Griddle />,
  document.getElementById('root')
);

There are some interfaces in my definition that would be really great for a developer to be able to consume, but I haven't found a good way to make it available. If I simply export them along side the true default export, they need to access it in a way that doesn't look so great:

import {default as Griddle, CustomColumnComponentProps} from 'griddle-react';

If I was able to declare a namespace that contained the interface that wasn't wrapped by typings in the ambient module declaration, they could gain direct access to the interface. Something resulting like:

declare namespace GriddleReact {
    export interface GriddleProps {
        someProp: string;
    }
}
declare module 'griddle-react' {
    export default class Griddle extends React.Component<GriddleReact.GriddleProps, any> {}
}

which could then be used like:

import Griddle from 'griddle-react';
var someProps: GriddleReact.GriddleProps = {someProp: 'prop'};

Is this frowned upon because it pollutes the environment with a namespace that the consumer may not be expecting? Any other thoughts or good ways to do this?

Typed Node

Should be able to write the node typing as a single file with dependencies on the native node modules - relies on typings/typings#1 working.

Repository Naming in typed-typings

<purpose>-<name>

  • env-atom, env-electron

<most common package manager>-<name>

  • “most common package manager” can still change (e.g. bower)
  • "most common package manager" is subjective.
  • npm is not likely to go away, but others not really sure (e.g. bower)
  • Also, I don’t like to “think and determine” what the name of the repo should be. And also don’t like to “look and discover it is only distributed in npm so I name it as npm-*”.

typed-<name>

  • typed- is redundant.

<owner>-<name>

  • Aware that some package transfer ownership (e.g. atom/electron to electron/electron)
  • Is it relatively rare?

Typed Express

Should be able to support Express.JS without ambient issues.

Integration with typescript compiler's typing discovery and location plan

This issue is to support/mirror discussion on #5537 but from the typings side.

While we've not yet nailed down a plan on what out endgame is in the compiler, one thing I know I'd certainly love to see typings do really well is discovery for a package's type information. We want to see users go from npm install bluebird --save to actually having the third-party types for that package (of the correct version!) available for them to depend on and use in editor and compilation experiences as seamlessly as possible.

@blakeembrey mentioned a resource for typings to use to automate discovery of typings, and potentially browse-able by humans. This would be excellent - potentially being able to locate the corresponding types for a series of package.json entries is a big step towards making finding existing types as seamless as possible. We'd love to know how your design and implementation with this proceed.

Pinging @mhegazy @ahejlsberg @vladima @DanielRosenwasser for their thoughts.

How developer maintains versions in registry ?

What do you think about letting each developer maintaining there own versions mapping inside their own typings.json (for simplicity purpose) and registry only mapping name => repo only like jspm registry does actually registry.json

{
  "name": "electron",
  "main": "electron.d.ts",
  "author": "koalabz <[email protected]>",
  "description": "The TypeScript definition for electron.atom.io",
  ...
  "versions": {
    "0.35.4": "#c597a7362eb4605ad737217a19b701d4cf2bc80a",
    "0.36.0": "#2689b1648190d6921496a3f94c0d4e1ecae2ef1f"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/koalabz/typed-electron.git"
  },
   ...
  }

Pros:

  • only one pull request needed the first time to map project => repos
  • easier for developer to maintain versions releases
  • typings.json didn't need extra
"ambientDependencies": {
    "node": "github:DefinitelyTyped/DefinitelyTyped/node/node.d.ts#5cb07b53719466b27cb32f3eb2c7c3e22575ecda"
  }

declarations but only the essential like package.jsondoes

"dependencies": {
    "bluebird": "^0.12.0"
 }

firmata.js typings

Hello! I am interested in finding a definition file for firmata.js (or in helping to generate one). The way I'm giving myself typescript support for firmata.js right now is INCREDIBLY HACKY. In fact, I know its the wrong way and I know all it is doing is keeping the compiler from complaining and helping provide me with some auto-completion. So I would really like some help in figuring out the right way to do this. Eventually I'd like to include a typings file in DefinitelyTyped so I can use $ typings search firmata and $ typings install --save --global dt~firmata.

What I have so far I use with

import { IBoard } from './interfaces/Firmata';

And the file Firmata.d.ts has this for its contents

/**
 * Created by troy on 9/19/16.
 */

// Most of these are generated by observing https://github.com/firmata/firmata.js/blob/master/lib/firmata.js

// TODO this can definitely be done better with a better understanding of prototypal inheritance

import SerialPort = require("serialport");

export interface IBoard
{
    // ==========
    // Properties
    // ==========
    MODES:{
        INPUT:number, OUTPUT:number, ANALOG:number, PWM:number, SERVO:number, SHIFT:number, I2C:number, ONEWIRE:number,
        STEPPER:number, SERIAL:number, PULLUP:number, IGNORE:number, PING_READ:number, UNKOWN:number
    },
    I2C_MODES:{ WRITE:number, READ:number, CONTINUOUS_READ:number, STOP_READING:number },
    STEPPER:{
        TYPE:{ DRIVER:number, TWO_WIRE:number, FOUR_WIRE:number },
        RUNSTATE:{ STOP:number, ACCEL:number, DECEL:number, RUN:number },
        DIRECTION:{ CCW:number, CW:number }
    },
    SERIAL_MODES:{ CONTINUOUS_READ:number, STOP_READING:number },
    SERIAL_PORT_IDs:{
        HW_SERIAL0:number, HW_SERIAL1:number, HW_SERIAL2:number, HW_SERIAL3:number,
        SW_SERIAL0:number, SW_SERIAL1:number,SW_SERIAL2:number, SW_SERIAL3:number, DEFAULT:number,
    },
    SERIAL_PIN_TYPES:{
        RES_RX0:number, RES_TX0:number, RES_RX1:number, RES_TX1:number,
        RES_RX2:number, RES_TX2:number, RES_RX3:number, RES_TX3:number,
    },
    HIGH:number,
    LOW:number,
    pins:[{
        mode:number,
        value:number,
        supportedModes:number[],
        analogChannel:number,
        state:number
    }],
    ports:number[],
    analogPins:number[],
    version:{},
    firmware:{
        name:string,
        version:{
            major:number,
            minor:number
        },
    },
    currentBuffer:number[],
    versionReceived:boolean,
    name:string,
    settings:IOptions,

    // TODO handle this more cleanly, currently a black box
    transport:SerialPort,

    // ====================
    // Constructor Function
    // ====================
    Board:(port:string|IPort, options?:IOptions, callback?:(err:any)=>void)=>IBoard,

    // =================
    // Prototype Methods
    // =================
    reportVersion:()=>void,
    queryFirmware:()=>void,
    analogRead:()=>void,
    analogWrite:()=>void,
    pwmWrite:()=>void,
    servoConfig:()=>void,
    servoWrite:()=>void,
    pinMode:(pin:number, mode:number)=>void,
    digitalWrite:(pin:number, val:number)=>void,
    digitalRead:(pin:number, callback:(val:number)=>void)=>void,
    queryCapabilities:()=>void,

    // TODO give these better definitions
    queryAnalogMapping:()=>void,
    queryPinState:()=>void,
    sendString:()=>void,
    sendI2CConfig:()=>void,
    i2cConfig:()=>void,
    sendI2CWriteRequest:()=>void,
    i2cWrite:()=>void,
    i2cWriteReg:()=>void,
    sendI2CReadRequest:()=>void,
    i2cRead:()=>void,
    i2cStop:()=>void,
    i2cReadOnce:()=>void,
    sendOneWireConfig:()=>void,
    sendOneWireSearch:()=>void,
    sendOneWireAlarmsSearch:()=>void,
    _sendOneWireSearch:()=>void,
    sendOneWireRead:()=>void,
    sendOneWireReset:()=>void,
    sendOneWireWrite:()=>void,
    sendOneWireDelay:()=>void,
    sendOneWireWriteAndRead:()=>void,
    _sendOneWireRequest:()=>void,

    setSamplingInterval:(interval:number)=>void,

    getSamplingInterval:()=>void,
    reportAnalogPin:()=>void,

    reportDigitalPin:(pin:number, value:number)=>void,

    pingRead:()=>void,

    stepperConfig:(deviceNum:number, type:number, stepsPerRev:number, dirOrMotor1Pin:number, stepOrMotor2Pin:number,
        motor3Pin?:number, motor4Pin?:number)=>void,
    // TODO define callback function better
    stepperStep:(deviceNum:number, direction:number, steps:number, speed:number, accel:number, decel:number,
        callback:Function)=>void,

    serialConfig:()=>void,
    serialWrite:()=>void,
    serialRead:()=>void,
    serialStop:()=>void,
    serialClose:()=>void,
    serialFlush:()=>void,
    serialListen:()=>void,
    sysexResponse:()=>void,
    sysexCommand:()=>void,
    reset:()=>void,

    // ==============
    // Static Methods (I think)
    // ==============
    isAcceptablePort:(port:IPort)=>boolean,
    requestPort:(callback:(err:any, port:IPort)=>any)=>void,
    encode:(data:number[])=>number[],
    decode:(data:number[])=>number[],


    // TODO define callback function better
    // TODO these need to be organized better
    on:(event:string, callback:Function)=>void,

    emit:(event:string)=>void,

    // ======
    // Custom (added by Joshua's firmata connector)
    // ======
    log:(message:any, ... optParams:any[])=>void,
    error:(message:any, ... optParams:any[])=>void,
    debug:(message:any, ... optParams:any[])=>void,
    info:(message:any, ... optParams:any[])=>void,
    warn:(message:any, ... optParams:any[])=>void,
}

interface IPort
{
    comName:string,
}

interface IOptions
{
    reportVersionTimeout?:number,
    samplingInterval?:number,
    serialPort?:{
        baudRate:number,
        bufferSize:number,
    }
}

As you can see, there are incomplete functions and I'm probably doing this the worst way possible, so any help is greatly appreciated.

Many modules are not found after updating to 1.0.4

E:\YAP>typings install github-electron --save
typings ERR! message Unable to find "github-electron" ("npm") in the registry. Did you want to try searching another source? Also, if you want contribute these typings, please help us: https://github.com/typings/registry
typings ERR! caused by https://api.typings.org/entries/npm/github-electron/versions/latest responded with 404, expected it to equal 200

typings ERR! cwd E:\YAP
typings ERR! system Windows_NT 10.0.10586
typings ERR! command "E:\Nodejs\node.exe" "C:\Users\Administrator\AppData\Roaming\npm\node_modules\typings\dist\bin.js" "install" "github-electron" "--save"
typings ERR! node -v v5.10.1
typings ERR! typings -v 1.0.4

Volunteer

Hey all, I'd like to volunteer to help move this project forward.
Please advise on where help is most needed.

Move typings

Make a "typed typings" organisation to hold all the typings being created "officially".

Improve/change logging

Could it because the error logging: typings ERR! message ... and so on are too "formal" and similar to npm error message so that when people see the error, they freak out and think there must be some fatal errors.

Therefore they file issue with the message attached instead of just reading the message and figure out why?

For sure we see this behavior a lot.
Maybe soften up the messages would help?

Configuring Aurelia

The Aurelia team has been doing a lot of work to make our d.ts support follow official recommendations. As such, we have a typings field in our package.json file for each library which points to the correct d.ts file. This works fine for users of our cli and webpack, however it doesn't work for jspm users. We know Microsoft has a new solution, but it doesn't seem to be ready so we'd like to support the typings tool for jspm users. We can place typings.json files into our repos, no problem. We've done this with one repo as a test: aurelia-pal. However, when we try to install that using typings, we always get the old version, not our currently released version from npm. I had a look at your registry and it seems that someone has created entries for this already. I'm wondering if that is causing the problem. If we added typings.json files to all our libraries and then removed your registry entries, would typings always grab the latest release from npm? Would that fix our issue?

(Apologies for the double post...I didn't see this repo earlier.)

Contributing typings

I'm interested in contributing some typings to an npm package I maintain. I've started writing it and added it to package.json like this

{
  "typings": "./my-package.d.ts"
}

In order to test it, I've created a separate consuming app and npm linked my package into it. Is there a way to get typings to use the typings in locally linked packages?

Also, once, I'm happy with my typings, will publishing the package with the typings file to npm be enough to make it available to users in typings by doing a typings install my-package?

Help for localForage

Hello @blakeembrey,

I would like to get typings for the localForage library and use those in my project.
At first, I tried using tsd and thus the following typings file: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/localForage/localForage.d.ts

Unfortunately, it imports the es6-promise typings and because Angular 2 (which I also use in my project) expose that already, I end up with the dreaded duplicate identifier error (on 'Promise'):

$ tsd install localForage

 - localForage    / localForage
   -> es6-promise > es6-promise

>> running install..

>> written 2 files:

    - es6-promise/es6-promise.d.ts
    - localForage/localForage.d.ts


$ tsc
node_modules/angular2/typings/es6-shim/es6-shim.d.ts(475,11): error TS2300: Duplicate identifier 'Promise'.
node_modules/angular2/typings/es6-shim/es6-shim.d.ts(552,13): error TS2300: Duplicate identifier 'Promise'.
typings/es6-promise/es6-promise.d.ts(11,15): error TS2300: Duplicate identifier 'Promise'.
typings/es6-promise/es6-promise.d.ts(42,16): error TS2300: Duplicate identifier 'Promise'.

Then, since I wanted to give your project a try, I've decided to give it a go, except that I don't really know where to start :)

I first tried a command that failed (can't remember what it was), which led me to fork the registry and try to add a reference towards definitelytyped for localForage: https://github.com/dsebastien/registry-1/commit/828d9998570d4d548f15f9eff9baa8f92e7cc239

Then I found the --ambient flag and realized that it's probably not worth a pull request (?).

Then I've tried typings install localForage --ambient --save which did find the typings on DefinitelyTyped and download those:

$ typings install localForage --ambient --save
? Found typings for localForage in DefinitelyTyped. Ok? Yes
Installing localForage@* (DefinitelyTyped)...

References (not installed):
  github:DefinitelyTyped/DefinitelyTyped/es6-promise/es6-promise.d.ts#c192586e9e3c5180e271dbd21e7295aaf1dcdbb6 (from localForage)

localForage
└── (No dependencies)

Unfortunately, tsc complains a bit afterwards:

$ tsc
typings/browser/ambient/localForage/localForage.d.ts(10,5): error TS2300: Duplicate identifier 'driver'.
typings/browser/ambient/localForage/localForage.d.ts(12,5): error TS2300: Duplicate identifier 'name'.
typings/browser/ambient/localForage/localForage.d.ts(14,5): error TS2300: Duplicate identifier 'size'.
typings/browser/ambient/localForage/localForage.d.ts(16,5): error TS2300: Duplicate identifier 'storeName'.
typings/browser/ambient/localForage/localForage.d.ts(18,5): error TS2300: Duplicate identifier 'version'.
typings/browser/ambient/localForage/localForage.d.ts(20,5): error TS2300: Duplicate identifier 'description'.
typings/browser/ambient/localForage/localForage.d.ts(24,5): error TS2300: Duplicate identifier '_driver'.
typings/browser/ambient/localForage/localForage.d.ts(28,5): error TS2300: Duplicate identifier '_support'.
typings/browser/ambient/localForage/localForage.d.ts(46,5): error TS2300: Duplicate identifier 'LOCALSTORAGE'.
typings/browser/ambient/localForage/localForage.d.ts(47,5): error TS2300: Duplicate identifier 'WEBSQL'.
typings/browser/ambient/localForage/localForage.d.ts(48,5): error TS2300: Duplicate identifier 'INDEXEDDB'.
typings/browser/ambient/localForage/localForage.d.ts(96,5): error TS2300: Duplicate identifier 'default'.
typings/main/ambient/localForage/localForage.d.ts(10,5): error TS2300: Duplicate identifier 'driver'.
typings/main/ambient/localForage/localForage.d.ts(12,5): error TS2300: Duplicate identifier 'name'.
typings/main/ambient/localForage/localForage.d.ts(14,5): error TS2300: Duplicate identifier 'size'.
typings/main/ambient/localForage/localForage.d.ts(16,5): error TS2300: Duplicate identifier 'storeName'.
typings/main/ambient/localForage/localForage.d.ts(18,5): error TS2300: Duplicate identifier 'version'.
typings/main/ambient/localForage/localForage.d.ts(20,5): error TS2300: Duplicate identifier 'description'.
typings/main/ambient/localForage/localForage.d.ts(24,5): error TS2300: Duplicate identifier '_driver'.
typings/main/ambient/localForage/localForage.d.ts(28,5): error TS2300: Duplicate identifier '_support'.
typings/main/ambient/localForage/localForage.d.ts(46,5): error TS2300: Duplicate identifier 'LOCALSTORAGE'.
typings/main/ambient/localForage/localForage.d.ts(47,5): error TS2300: Duplicate identifier 'WEBSQL'.
typings/main/ambient/localForage/localForage.d.ts(48,5): error TS2300: Duplicate identifier 'INDEXEDDB'.
typings/main/ambient/localForage/localForage.d.ts(96,5): error TS2300: Duplicate identifier 'default'.

Now I'm wondering how to fix this. I assume that removing either the contents of the browser folder or the ambient one would fix this, but is it the way to do?
Am I missing some other flag?

Or do I need to create some other type of module (i.e., non-ambient) like https://github.com/typings/typed-debug from the info I have on DefinitelyTyped?

Any pointers will be very appreciated :)

Where are the docs for writing a typings.json file?

I've been poking around but can't seem to find the documentation for writings typings.json files. I've got some basics in place but need to do something a bit different. I need a repo to not have a main but instead a list of d.ts files that it exports. I'm thinking I could add a files property and list them, but I can't find any docs to confirm that.

Typings install gives 502

i am trying to install typings using script command in npm : typings install && typings prune

I get the following error:
https://api.typings.org/entries/dt/core-js/tags/0.0.0%2B20160914114559 responded with 502, expected it to equal 200

Things i have tried is

  1. resetting the http and https proxy
  2. setting strict ssl to false
  3. using .typingssrc file this file contains
    {
    "proxy": "http://proxy:8080",
    "defaultSource": "dt"
    }

Even then i am getting the above error, i suspect it is a proxy issue. Can someone please help me resolve this

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.