Fixing common TS typings

[pklaschka]

@Velara

Matrix
[ts] Property ‘e’ does not exist on type ‘Matrix’. [2339]

var transform = item.transform;
transform.e = 0;

As per the documentation, Matrix has no attribute e: Matrix · Adobe XD Plugin Reference

@Velara

Module

[ts] Cannot find module ‘os’. [2307]

const platform = require("os").platform();

OS – according to the docs – is a global class and therefore not a module that can get imported by using require() – cf. OS · Adobe XD Plugin Reference

@Velara

File

[ts] Type ‘File | File’ is not assignable to type ‘File’.
Type ‘File’ is missing the following properties from type ‘File’: lastModified, size, type, slice [2322]

 /**@type {File} */
 let selectedFile = await fileSystem.getFileForOpening();

This could be an interference with the File type from the “standard” DOM typings (see File - Web APIs | MDN). I – unfortunately – haven’t found a way to get around that (except for disabling the DOM typings which would mean not having capabilities around the UI aspects).

@Velara

[ts] Property ‘nativePath’ does not exist on type ‘File’. [2339]

var value = selectedFile.nativePath;

I would guess that this is the same problem as above. Again, that’s due to an incompatibility of some aspects of the XD APIs with the way typescript handles things (more on that later )

@Velara

[ts] Property ‘read’ does not exist on type ‘Entry’. [2339]

const entries = await pluginDataFolder.getEntries();
const files = await entries.filter(entry => entry.name.indexOf(filename) >= 0);
var file = files[0];
let data = await file.read();

That’s to be expected since at that point, file is only known to be an Entry, and only a File has the property read(). Unfortunately, that’s a point where there’s a big incompatibility between the way the APIs work and the way typescript works. With the APIs, we would simply check for the Entry being a File by using entry.isFile(), but TypeScript – unfortunately – doesn’t support something like this, which is why there is no good solution for this (at least none that I’m aware of and I’ve searched for a long time when developing the definitions).

@Velara

[ts] Property ‘write’ does not exist on type ‘Folder | File’.
Property ‘write’ does not exist on type ‘Folder’. [2339]

newFile.write(data);

Same as above.

@Velara

[ts] Cannot find name ‘Folder’. [2304]

 /** @type { Folder } */
 const folder = await pluginFolder.getEntry(filePath);

Since Folder isn’t an exported member of the module, it seems to have difficulties to resolve that name. Unfortunately, I don’t know of any way around that (sometimes it works, sometimes it doesn’t).

@Velara

Color

[ts] Property ‘serialize’ does not exist on type ‘Color’. [2339]

console.log("Color:" + new Color("red").serialize()); // returns "rgb(255, 0, 0)" 

While it’s interesting to hear about that serialize() method, it isn’t stated anywhere in the docs and therefore not inlcuded in the typings (since it is my goal to keep those up to date with the docs where I have docs to copy etc. and not with some “mysterious, hidden APIs” ) – cf. Color · Adobe XD Plugin Reference

@Velara

SceneNode

[ts] Type ‘SceneNode’ cannot be used as an index type. [2538]

itemsDictionary[sceneNode] = nestLevel;

That’s due to the way TypeScript handles index types. Please refer to https://basarat.gitbooks.io/typescript/docs/types/index-signatures.html for further information about index signatures in anything related to TypeScript. The short version is, that you could use sceneNode.toString() to hack your way around that and otherwise can’t use complex data structures as index types (out of curiosity: why would you want to do that anyway? It seems a bit strange to me since once you loose the reference of an object, you’ll never be able to access the elements of the dictionary anymore?)