node-serialport icon indicating copy to clipboard operation
node-serialport copied to clipboard

Invalid PortInfo typscript declaration

Open loucass003 opened this issue 2 years ago • 4 comments
trafficstars

SerialPort Version

10.5.0

Node Version

v18.10.0

Electron Version

No response

Platform

Microsoft Windows NT 10.0.22621.0 x64

Architecture

x64

Hardware or chipset of serialport

USB-SERIAL CH340

What steps will reproduce the bug?

const [first] = await SerialPort.list();
  
console.log(first);

What happens?

that code gives me back

     path: 'COM5',
     manufacturer: 'wch.cn',
     serialNumber: '6&28CF390B&0&5',
     pnpId: 'USB\\VID_1A86&PID_7523\\6&28CF390B&0&5',
     locationId: 'Port_#0005.Hub_#0001',
     friendlyName: 'USB-SERIAL CH340 (COM5)',
     vendorId: '1A86',
     productId: '7523'
}

the output is correct but the type deffinition is wrong

What should have happened?

on the portInfo definition there is only

export declare interface PortInfo {
    path: string;
    manufacturer: string | undefined;
    serialNumber: string | undefined;
    pnpId: string | undefined;
    locationId: string | undefined;
    productId: string | undefined;
    vendorId: string | undefined;
}

the friendlyName is missing from this definition but is acutally there in the sent object

Additional information

No response

loucass003 avatar Feb 15 '23 23:02 loucass003

After hitting F12 to see signature of list() api, I can see that this should work:

import { PortInfo } from "@serialport/bindings-cpp";

bluephoton avatar Feb 21 '23 00:02 bluephoton

@reconbot I recall we had a chat about friendlyName a while ago and decided against including it, but I think I might have accidently pulled in it as part of the NAPI changes :-(

Would you prefer we remove friendlyName again or add it into the type definitions?

GazHank avatar Jun 07 '23 11:06 GazHank

Fine by me. Up to you.

reconbot avatar Jun 07 '23 16:06 reconbot

I guess the safest option is to add it to the type definition in case people are using it...

on a similar basis I wonder if making it optional and therefore avoiding setting this as undefined for unix based platforms makes more sense, after all I think we need Windows to be able to use iehter a string or undefined... so this would mean:

friendlyName?: string | undefined rather than friendlyName: string | undefined

I haven't used typescript a great deal, so open to suggestions as to what is preferable. I'm especially keen to make sure any change in this area does increase the amount of system specific code being written accidentally.

GazHank avatar Jun 08 '23 14:06 GazHank