Strange error in script editor interface for variables after getObject()

[PeterVoronov]

Describe the bug
It's simple - in the script, I use getObject function, and when I tried to use properties of the common field of received object - it's marked mostly by error, for all properties, except name, role, icon.
To Reproduce
Steps to reproduce the behavior:

1. Write a simple JavaScript in editor, like :

var test ='web.0.connected';
var obj = getObject(test);
log('obj = ' + JSON.stringify(obj));
var write = obj.common.write;
log('write = ' + JSON.stringify(write));

2. Property write will be marked as wrong.
3. Move mouse pointer on it:
   
4. Click on 'Alt+F8'
5. Will see 'Property 'write' does not exist on type 'StateCommon | ObjectCommon | ChannelCommon | OtherCommon'.
   Property 'write' does not exist on type 'ObjectCommon'.(2339)'
   
6. More over, when you tried to get possible properties during edit - the same limit is applied:

6

. Despite this messages, the object common property has whit write property and much more, not only name, role, icon - see the log:

2021-05-09 12:43:02.795  - .[32minfo.[39m: javascript.0 (12707) Start javascript script.js.Test.Script_1_test
2021-05-09 12:43:02.802  - .[32minfo.[39m: javascript.0 (12707) script.js.Test.Script_1_test: obj = {"_id":"web.0.connected","type":"state","common":{"role":"text","name":"Active instances","type":"string","
read":true,"write":false},"native":{},"acl":{"object":1636,"state":1636,"owner":"system.user.admin","ownerGroup":"system.group.administrator"},"from":"system.adapter.web.0","user":"system.user.admin","ts":16
20432332016}
2021-05-09 12:43:02.802  - .[32minfo.[39m: javascript.0 (12707) script.js.Test.Script_1_test: write = false
2021-05-09 12:43:02.802  - .[32minfo.[39m: javascript.0 (12707) script.js.Test.Script_1_test: registered 0 subscriptions and 0 schedules

Expected behavior
Proposal for properties of property common has to display all possible field, and no error marks, for write and other properties.

Screenshots & Logfiles
See above.

Versions:

• Adapter version: 5.1.3
• JS-Controller version: 3.2.16
• Node version: v12.22.1
• Operating system: Debian Buster

Additional context
I tried to find similar previous issues, but may be I'm not good in it. If it double - excuse me, but it is annoying.

[Apollon77]

@AlCalzone Error in Typings?

[AlCalzone]

More like code that Typescript cannot prove to be correct.

@PeterVoronov can you try

const obj = getObject('web.0.connected');

Instead of

var test ='web.0.connected';
var obj = getObject(test);

[AlCalzone]

Actually, shouldn't it be web.0.info.connected?

[PeterVoronov]

More like code that Typescript cannot prove to be correct.

@PeterVoronov can you try

const obj = getObject('web.0.connected');

Instead of

var test ='web.0.connected';
var obj = getObject(test);

web.0.info.connected is only example.
I see the same behavior for any state, which was got
via getObject.
And the behavior with you example the same...

[PeterVoronov]

More like code that Typescript cannot prove to be correct.

@PeterVoronov can you try

const obj = getObject('web.0.connected');

Instead of

var test ='web.0.connected';
var obj = getObject(test);

Moreover - usually, in "big" scripts the variables is used, instead exact strings...

I put the example of code, similar to what I have in real scripts...

[AlCalzone]

Okay, first off: I just realized the improvements to detecting the object types from the ID are only in @types/iobroker, but never made their way into the script editor typings.

Second: This is never going to be perfect for all use cases due to the way the script editor's syntax help (TypeScript) works. getObject returns an object that can be any one of ioBroker's object types. Depending on the ID you put in, the syntax help can exclude some types that it cannot return in this case. But if any of these remaining possible types does not include the read or write properties in the common part, you won't be offered these properties in auto-completion.

To be able to offer the correct options, the IDs that are used to infer the possible object types must have a certain format. I've pushed with the TypeScript team to bring this functionality as close as possible to what we need. But depending on how you construct these IDs, especially by using var instead of const, this won't be enough. Once I've included the improved typings from @types/iobroker here, this will work:

const test = 'web.0.info.connected';
const obj = getObject(test);

but this won't

var test = 'web.0.info.connected';
var obj = getObject(test);

However, there's a workaround you can already use now. You just need to tell the editor that obj is a StateObject. This looks a bit weird though because you'll need the extra brackets around getObject:

[PeterVoronov]

Okay, first off: I just realized the improvements to detecting the object types from the ID are only in @types/iobroker, but never made their way into the script editor typings.

Second: This is never going to be perfect for all use cases due to the way the script editor's syntax help (TypeScript) works. getObject returns an object that can be any one of ioBroker's object types. Depending on the ID you put in, the syntax help can exclude some types that it cannot return in this case. But if any of these remaining possible types does not include the read or write properties in the common part, you won't be offered these properties in auto-completion.

To be able to offer the correct options, the IDs that are used to infer the possible object types must have a certain format. I've pushed with the TypeScript team to bring this functionality as close as possible to what we need. But depending on how you construct these IDs, especially by using var instead of const, this won't be enough. Once I've included the improved typings from @types/iobroker here, this will work:

const test = 'web.0.info.connected';
const obj = getObject(test);

but this won't

var test = 'web.0.info.connected';
var obj = getObject(test);

However, there's a workaround you can already use now. You just need to tell the editor that obj is a StateObject. This looks a bit weird though because you'll need the extra brackets around getObject:

Thanks, will try and check...

[PeterVoronov]

Okay, first off: I just realized the improvements to detecting the object types from the ID are only in @types/iobroker, but never made their way into the script editor typings.

Second: This is never going to be perfect for all use cases due to the way the script editor's syntax help (TypeScript) works. getObject returns an object that can be any one of ioBroker's object types. Depending on the ID you put in, the syntax help can exclude some types that it cannot return in this case. But if any of these remaining possible types does not include the read or write properties in the common part, you won't be offered these properties in auto-completion.

To be able to offer the correct options, the IDs that are used to infer the possible object types must have a certain format. I've pushed with the TypeScript team to bring this functionality as close as possible to what we need. But depending on how you construct these IDs, especially by using var instead of const, this won't be enough. Once I've included the improved typings from @types/iobroker here, this will work:

const test = 'web.0.info.connected';
const obj = getObject(test);

but this won't

var test = 'web.0.info.connected';
var obj = getObject(test);

However, there's a workaround you can already use now. You just need to tell the editor that obj is a StateObject. This looks a bit weird though because you'll need the extra brackets around getObject:

1. Excuse me, but doesn't work.
   
   

2.And, as I said - using const and placing the exact sting as parameter in getObject - is not useful for scripts, where the object id can be calculated, or , provided as parameter to function, which have the getObject call inside ...

[AlCalzone]

1. It isn't done yet - I quote myself:

I just realized the improvements to detecting the object types from the ID [...] never made their way into the script editor typings.
Once I've included the improved typings from @types/iobroker here, this will work:

You missed the most important part of the workaround by the way... Look at line 9 in my screenshot.

using const and placing the exact sting as parameter in getObject - is not useful for scripts, where the object id can be calculated, or , provided as parameter to function, which have the getObject call inside ...

Yeah, but there's not much we can do about it. If the script editor cannot know for sure that you're trying to access a state object, it cannot know that what you're doing is correct and/or that this object actually has a common.write property. In these case you need to tell the editor that it is using the @type comment - or ignore the errors.

[PeterVoronov]

1. It isn't done yet - I quote myself:

I just realized the improvements to detecting the object types from the ID [...] never made their way into the script editor typings.
Once I've included the improved typings from @types/iobroker here, this will work:

You missed the most important part of the workaround by the way... Look at line 9 in my screenshot.

using const and placing the exact sting as parameter in getObject - is not useful for scripts, where the object id can be calculated, or , provided as parameter to function, which have the getObject call inside ...

Yeah, but there's not much we can do about it. If the script editor cannot know for sure that you're trying to access a state object, it cannot know that what you're doing is correct and/or that this object actually has a common.write property. In these case you need to tell the editor that it is using the @type comment - or ignore the errors.

Excuse me, missed this. Looks like it working. Thanks.

[AlCalzone]

FYI this should work when #878 is merged and released.