It seems both StructureContainer and Spawn is missing the extends Structure in declaration.

I am very new to the game, so I might be overlooking something though. The error I'm getting is I cannot use them as RoomObject in i.e. moveTo

RoomVisual constructor needs to have roomName as optional: http://docs.screeps.com/api/#RoomVisual

TextStyle needs 3 additional optional, I have extended it using:
interface TextStyle {
font?: string | number;
stroke?: string;
strokeWidth?: number;
}
http://docs.screeps.com/api/#RoomVisual.text

It seems that currently, you can't apply an interface to members of the built-in Memory objects (such as Memory.creeps) because they're defined in index.d.ts as any. I'd like to propose making a dummy interface for each of the four built-in Memory objects so that a player can then extend those interfaces in their own definition files.

For example, say I make my own interface for a room's memory:

interface MemRoom {
  name: string;
  type: string;
  threat: boolean;
}

If I try to apply it to Memory as follows:

interface Memory {
  rooms: {
    [name: string]: MemRoom;
  };
}

Then with the current typings I will get this error:

error TS2403: Subsequent variable declarations must have the same type.  Variable 'rooms' must be of type '{ [name: string]: any; }', but here has type '{ [name: string]: MemRoom; }'.

If however, there were already a "dummy" interface in the typings called MemRoom:

interface Memory {
    [name: string]: any;
    ...
    rooms: {
        [name: string]: MemRoom;
    };
    ...
}
interface MemRoom {
  [name: string]: any;
}
declare class Room {
  ...
    /**
     * A shorthand to Memory.rooms[room.name]. You can use it for quick access the room’s specific memory data object.
     */
    memory: MemRoom;
  ...
}

Then I could extend MemRoom to give specific types to any variables I want (as I tried to do above). This could be done for all four default Memory objects, and would allow users to type things that they want to store in memory - a huge advantage, I think, since Memory is the biggest source of errors for me these days!

If there is already a way to accomplish this that doesn't require modifying the current screeps declarations, please let me know as I'd be very curious!

It seems that, since the definition for Map has no accessible constructor, we should be able to just rename it to something that doesn't conflict, so the Map type is usable for non-string dictionary keys?

Thanks for creating and keeping this updated.

I noticed issues compiling and I think I see the problem but I'm pretty new at this.
It's the declarations for Game.rooms/flags/creeps etc. Instead of just an array, shouldn't they be like this?

  creeps: {[creepName: string]: Creep};
  rooms: {[roomName: string]: Room};
  spawns: {[spawnName: string]: Spawn};
  structures: {[structureId: string]: Structure};

Throughout the declarations there are many occurrences of 1-tuples where it should have been an array.

[string] is a 1-tuple containing 1 element of type string.

string[] is an array of string elements.

And what is even more confusing is that tuples are bugged in TypeScript, allowing to use more elements than defined: microsoft/TypeScript#6229

An example of this issue in the present declarations:

RoomPosition.findClosestByRange<T>(objects: [T|RoomPosition], opts?: {filter: any|string }): T;

Which should actually be:

RoomPosition.findClosestByRange<T>(objects: T[]|RoomPosition[], opts?: {filter: any|string }): T;

I will try to fix all of them and do a pull request.

If the creep exists, it can see the room it's in. Unfortunately, the types don't reflect this and accesses without guards will cause TS errors.

Room.createFlag should have the name and color parameters optional according to Screeps API Docs
http://support.screeps.com/hc/en-us/articles/203079011-Room

It's a documented alias for FIND_DROPPED_RESOURCES but it's missing from the declarations.

Hello there!

I'm struggling with setting up unit tests that depend on Screeps types.

For example, when trying to extend Creeps like this:

Creep.prototype.someFunction = ...

My IDE is happy, the compiled code runs in game just fine, all types are resolved. But, when executing a unit test that imports the above code, it always fails with

ReferenceError: Creep is not defined

How to teach ts-jest to look at the right place and resolve Creep and other types located in node_modules/@types/screeps/index.d.ts ?

Thank you in advance!

recycleCreep should be in Spawn.
http://support.screeps.com/hc/en-us/articles/205990342-StructureSpawn

Isn't that what we were waiting for to change it over to the new master?

From the documentation: http://support.screeps.com/hc/en-us/articles/208488525-Nuke

This is the class for an actual Nuke landing position, and it doesn't appear to be in the TypeScript declarations at all.

http://docs.screeps.com/api/#Room.createFlag
http://docs.screeps.com/api/#RoomPosition.createFlag

Just add | string and we good.

In screeps, there's an object global which can be used to store values globally (i.e. for use from the console). It should be as simple as adding a declare var global:any; in the code, but I'm not sure where it should be put (hence an issue instead of a PR)

Think it should be declared as a string for named array, compiler was balking til I changed it.

interface LookAtResultMatrix {
    [coord: string]: LookAtResultMatrix|LookAtResult[]
}

I added the question marks (?) to the opts object. This was causing my code to throw errors since I was only using filter and not specifying the algorithm (using the default).

    /**
     * Find an object with the shortest path from the given position. Uses A* search algorithm and Dijkstra's algorithm.
     * @param type See Room.find
     * @param opts An object containing pathfinding options (see Room.findPath), or one of the following: filter, algorithm
     */
    findClosestByPath<T>(type: number, opts?: {
        filter?: any | string;
        algorithm?: string;
    }): T;
    /**
     * Find an object with the shortest path from the given position. Uses A* search algorithm and Dijkstra's algorithm.
     * @param objects An array of room's objects or RoomPosition objects that the search should be executed against.
     * @param opts An object containing pathfinding options (see Room.findPath), or one of the following: filter, algorithm
     */
    findClosestByPath<T>(objects: [T | RoomPosition], opts?: {
        filter?: any | string;
        algorithm?: string;
    }): T;

I just had a move across the planet and didn't get your message until now. I will take over the repo and package if you don't want to maintain them anymore

I had problems using a variable of Source | Ressource, as instanceof only works for classes it seems, and I need to narrow the type for a function call to Creep.harvest. Should Source be a class, or is there another way to narrow the type?

http://docs.screeps.com/api/#RoomVisual.constructor
The roomName is optional in the constructor per the API but it is not in the declarations file

Needs to be added to end.

declare var CONSTRUCTION_COST: {
    spawn: number;
    extension: number;
    road: number;
    constructedWall: number;
    rampart: number;
    link: number;
    storage: number;
    tower: number;
    observer: number;
    powerSpawn: number;
    extractor: number;
    lab: number;
    terminal: number;
    container: number;
    nuker: number;
};

Currently TypeScript rejects this if condition:

s instanceof StructureSpawn

since StructureSpawn is defined as a type, not a class. However, this works:

s instanceof Spawn

This is somewhat annoying, since the two do seem to be interchangeable. The docs, for what it's worth, specifically refer to the class/prototype as "StructureSpawn" (not "Spawn"): http://support.screeps.com/hc/en-us/articles/205990342-StructureSpawn

Ignore me

http://blog.screeps.com/2017/09/changelog-2017-09-28/ for details.

Despite what the documentation says, the method inRangeTo can accept any object that has a property pos with properties x, y and roomName as first parameter. It doesn't even have to be of type RoomPosition.
(source)

Wouldn't it make more sense to have the screeps.d.ts generated with 'Interfaces' instead of 'declare class'? This repo isn't providing any implementation, its more used as a type system.

See (https://stackoverflow.com/questions/14311675/typescript-declaration-files-contain-class-definitions-with-no-member-implementa/14323673#14323673 and
https://stackoverflow.com/questions/14345485/whats-the-difference-between-declare-class-and-interface-in-typescript)

I'm honestly not sure how this can be handled...

This would provide a much easier way to use definitions, including IDEs like WebStorm.
http://definitelytyped.org/guides/contributing.html

http://support.screeps.com/hc/en-us/articles/207728995-Changelog-2016-02-19

Docs:

http://docs.screeps.com/api/#Constants

STRUCTURE_WALL: "constructedWall",

it was deprecated. It's gone now

With some uses of literal types, we can allow body part typings to accurately reflect their values while not affecting backward compatibility with those who are using the existing typings:

This can also be extended to other locations such as the Direction types.

I recently imported screeps.d.ts and noticed that there were a few issues related to literal values assigned to game constants. Previously they were declared like this:

declare const SOURCE_ENERGY_CAPACITY: number;

Now they are declared like this:

declare const SOURCE_ENERGY_CAPACITY: 3000;

This caused a lot of compiler errors, here is an example:

let score = SOURCE_ENERGY_CAPACITY;
if (WorldMap.roomTypeFromName(sourcePos.roomName) === ROOMTYPE_SOURCEKEEPER) {
    // TS2322: Type '4000' is not assignable to type '3000'
    score = SOURCE_ENERGY_KEEPER_CAPACITY;
}

I'm curious about the rationale for this specific way of declaring types and what situations that it would help. I'm also wondering if there is some setting that I can use to allow it to understand that I'm aiming for a number type here.

typings are deprecated )