Linter marks working code of table creation when table not exists , is it bug?

[Alexey_Gusev]

Hi,

My script is working OK but make some red marks where shouldn’t be (i think).
the script is quite complex and divided into parts, designed to work in different bases, related to old tables inventory and cleanup, so I avoid hardcoding Table/Names outside of beginning const values
Here, it marks red for ‘FinalTableX’ not existed in base, but not marks if I put ‘FinalTable’ existed.

I think that’s incorrect behaviour, because that piece is intended to “check table, create if not exist or use existing”, maybe remains from past months, before great breaktrough with create table by script.
I think, same with fields. Commented function also cause marking FIELDS, i changed it because i suddenly need second field to be Multitext.

Including text source

const FIELDS=[‘Name’,‘List’,‘Info’,‘button’];
const ROOTTABLE=‘FinalTable’;
let tableNames=base.tables.map(table=>table.name);
if (!tableNames.includes(ROOTTABLE)) { //createRootTable;
const tableId = await base.createTableAsync(ROOTTABLE,FIELDS.map(rootFields));
function rootFields(fld,ix){
return {name:fld,type:((–ix)? ‘singleL’:‘multil’)+‘ineText’}};
//return {name:fld,type:‘singleLineText’}};

[kuovonne]

I find the linter to be overly picky and it marks code that is completely functional. Airtable also periodically adjust the linter. Things that the linter used to be okay with now gets flagged and things that used to get flagged now aren’t. Now, if I am sure the code is correct, I ignore the wavy red underlines.

[Dominik_Bosnjak]

Just out of curiosity, what does the hover action actually say about the error, @Alexey_Gusev? A lot of issues revolving around overly zealous linting stem from the fact that we’re writing JavaScript with default Monaco (web worker?) settings.

Meaning the target syntax is… a bit conservative:

monaco.languages.typescript.ScriptTarget.ES2015

And that’s without even accounting for the fact the Scripting app scripts aren’t actually .ts but .js files. So versioning aside, the settings seem to be flat-out wrong. We’re not writing TypeScript/nothing gets compiled so we can’t actually benefit from using its typing system. In fact, just about the only thing that works are the linting errors. Somehow, I’m thinking whoever’s responsible for the Scripting app considers it a feature, not a bug. Given how long this has been a widely reported annoyance - to no effect.

But anyway, optional chaining can help with some typing mismatches, especially given how the linter is… not particularly accurate even in ideal conditions.

Optional chaining is when you add “?” as a prefix to dot-notation accessors.

That error on line four might be avoidable using the said technique:

 if(!tableNames?.includes(ROOTTABLE)) {...

Otherwise, map //@ts-ignore to a hotkey, or start disabling linting altogether by adding //@ts-nocheck to the top of your scripts.

[Alexey_Gusev]

I tried optional chaining before, but that not helped.
linter says

Argument of type ‘“FinalTableX”’ is not assignable to parameter of type …“FinalTable” | “Table1” | “Table2” | … listing of all tables in a base

The error disappears when I change ROOTTABLE to one of them.
So, linter worries not about “what if tableNames undefined etc” (case for optional chaining) ,
it gets tableNames not for array of strings, but for array of existing table.names
that confused me - why linter doing that check (for table existence in base)?

after reading your reply I decided that the linter is not “checking existence”, it gets expression as “different types comparsion”, which is possible in JS, but not allowed in “strong type” languages. Fixed it by (table=>table.name.toString()) for now.
Also, it feels like i need to know more about “what is ES2015”, so thanks for your answer.