Skip to main content

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

  • September 10, 2021
  • 3 replies
  • 0 views
Alexey_Gusev
Forum|alt.badge.img+12

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’}};

    3 replies

    kuovonne
    Forum|alt.badge.img+17
    • kuovonne
    • Brainy
    • 5997 replies
    • September 10, 2021

    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.

    D
    Alexey_Gusev
    2 people like this
    • D
      Dominik_Bosnjak
    • Alexey_Gusev
      Alexey_Gusev
    D

    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
    1 person likes this
    • Alexey_Gusev
      Alexey_Gusev
    Alexey_Gusev
    Forum|alt.badge.img+12
    • Alexey_Gusev
    • Author
    • Brainy
    • 1119 replies
    • September 12, 2021
    Dominik_Bosnjak wrote:

    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.


    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.

    Reply


    Most helpful members this week

    Terms & Conditions