Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:00
    typescript-bot closed #40781
  • 20:00
    typescript-bot closed #40796
  • 19:26
    yume-chan edited #40857
  • 19:26
    typescript-bot labeled #40858
  • 19:26
    yume-chan opened #40858
  • 19:25
    a-tarasyuk converted_to_draft #40653
  • 19:23
    yume-chan opened #40857
  • 18:51
    DanielRosenwasser assigned #40650
  • 18:51
    DanielRosenwasser assigned #40650
  • 18:11
    LXSMNSYC closed #40850
  • 18:00
    typescript-bot closed #40780
  • 18:00
    typescript-bot closed #40792
  • 17:57
    RyanCavanaugh labeled #40855
  • 17:56
    RyanCavanaugh closed #40856
  • 17:55
    LastDragon-ru edited #40856
  • 17:55
    typescript-bot synchronize #40748
  • 17:55
    LastDragon-ru edited #40856
  • 17:54
    LastDragon-ru opened #40856
  • 17:53
    humkins edited #40854
  • 17:35
    mjbvz unassigned #40854
Reko Tiira
@rekotiira
hmm actually it seems that our tsconfig.json only has alwaysStrict set to true, but not strict
webstrand
@webstrand
ah "alwaysStrict" is just for added "use strict" to every file
Reko Tiira
@rekotiira
yeah seems so
webstrand
@webstrand
strict is the one that provides additional type safety
NoInfer doesn't work without strictNullChecks (which is implied by strict)
Reko Tiira
@rekotiira
seems like enabling produces quite a bit of errors in our project's codebase :D but I think it's probably going to be a good idea to go through these and fix them
webstrand
@webstrand
yeah, I really, really recommend using strict
Reko Tiira
@rekotiira
well strictNullChecks we actually do have set to true explicitly
could it be the strictFunctionTypes that does the magic?
webstrand
@webstrand
oh yeah, that's the one
Reko Tiira
@rekotiira
thanks a ton, this has been bugging me for days :laughing: should've come and ask about it earlier
I guess there's no way force that error without strict mode? This is library code, so would be nice if anyone using the library would get the error.
webstrand
@webstrand
Nope, it's one of the sad parts of Typescript that they've resisted enabling strict by default
And there's no way to force it from a library
Reko Tiira
@rekotiira
Well I'll take what I can get. If at least I can avoid people from making mistakes in our own project, that's better than nothing :)
Thanks again!
webstrand
@webstrand
most projects use strict, only legacy applications tend to have it disabled
Reko Tiira
@rekotiira
well that's good to hear at least
seems like in strict mode even without NoInfer it gives you an error. then the error is just for the wrapped type arg, while with NoInfer you get the error for the func arg, which is nicer
webstrand
@webstrand
Without strict function types, function arguments are considered "bivariant" more here
Reko Tiira
@rekotiira
@webstrand thanks for the information!
webstrand
@webstrand
I have some files *.script.ts in my code base that are executable scripts. Since they run in a different environement from the rest of my code, they can't share the project's tsconfig.json (which explicitly excludes **/*.script.ts).
vscode is reporting errors in those files due to ES2019 features, is there any way I can set another tsconfig file for .script.ts files?
Salathiel Genèse
@SalathielGenese

Hi everyone,

I have a package - @my/package
It comes with some predefined types.

Now, in @my/project, I linked to @my/package...
But I don't seem to be able to pick on those global types.

How should I go about it, please ?

Raziel
@rraziel
You mean you want its types without importing them?
Salathiel Genèse
@SalathielGenese
Yes @rraziel
That's the spirit
Raziel
@rraziel
Hm then it's tsconfig's typeRoots (iirc)?
Or types
Salathiel Genèse
@SalathielGenese
Hmmmm
Will give it a shot
But I tried types yesterday without much success
darsain
@darsain

I'm running into this kind of issue quite often, where TS complains that bar in returned function is possibly null even though it can't be:

declare function maybeGetList(): any[] | null;

function foo(value: any) {
    let bar = maybeGetList();
    if (!bar) bar = [];
    bar.push(value);
    return () => {
        let index = bar.indexOf(5);
        if (index >= 0) bar.splice(index, 1);
    };
}

what is the most polite way to tell TS to shut up?

or do I have to resort to bar!?
webstrand
@webstrand
let bar = maybeGetList() ?? []; would work
but, yeah, sometimes you have to fall back on using ! or put a runtime check in your anonymous function
@darsain
darsain
@darsain
can't do that. in my real code I need to do more things in that if (!bar) condition
welp, ! it is I guess :/
webstrand
@webstrand
alternatively, you can do const x = bar; and use `x in place of bar.
the issue is, typescript only keeps narrowed types around in the same context. In lambdas, since the type of let bar is [] | null, and since it can't prove that the lambda can only be called when bar is narrowed to [], it forgets the narrowing.
technically, it could prove that condition, but it currently doesn't.
assigning to another variable shouldn't affect performance
webstrand
@webstrand
for example,
declare function maybeGetList(): any[] | null;

function foo(value: any) {
    let bar = maybeGetList();
    let lambda = () => {};
    if (!bar) {
        bar = [];
        lambda = () => {
            let index = bar!.indexOf(5);
            if (index >= 0) bar!.splice(index, 1);
        };
    }
    bar = null;

    return lambda;
}
is a case where bar isn't permenantly narrowed
darsain
@darsain
yeah but it's one of those things that makes ugly code where you have useless lines just to satisfy checker, and will cause confusion in future.
dude that will read the code after me will be like "wtf, why is he reassigning here", remove the line, than get errors, get confused, and waste some time of his life getting to the "oh" moment :)
webstrand
@webstrand
honestly, getting real errors back when you make an invalid modification to the code is a lot nicer than getting nothing with ! assertions
@darsain Final alternative, this one is my least favourite:
    let bar = (() => {
        let bar = maybeGetList();
        if(!bar) bar = [];
        /* ... */
        return bar;
    })();
because it will have overhead
whereas const is basically free these days