Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any way to suppress typing errors in JS kernel? #54

Open
athewsey opened this issue Apr 29, 2021 · 1 comment
Open

Any way to suppress typing errors in JS kernel? #54

athewsey opened this issue Apr 29, 2021 · 1 comment

Comments

@athewsey
Copy link

(Sorry to bombard with issues lately! I think this one is again separate, but likely linked to #38)

I'm seeing the JavaScript/jslab kernel raise errors on module imports that shouldn't be a problem in plain JavaScript.

For instance, referring to the TensorFlow.js MNIST node example, if I:

const data = require("./data");

...I'm seeing:

181:35 - Argument of type 'number[]' is not assignable to parameter of type '[number, number, number, number]'.
181:35 - Target requires 4 element(s) but source may have fewer.

I appreciate that by some perspectives this is a good thing, and even in the README this project calls out that it provides "Type safety even in JavaScript mode".

...but in JS mode we don't have the option of simply suppressing the checks by e.g. adding e.g. as any, since that's TS-specific syntax - even assuming we're able to edit the source file.

Is there any way to turn off type checking either locally or globally for the JS kernel?

@fctlb
Copy link

fctlb commented Dec 28, 2023

@athewsey I am looking for the same currently, wish any of the authors (@yunabe, @yannisgu, @tiagosiebler) could help.

To you guys, tslab is wonderful, I am using it to create educational material, but this issue of mandatory type-checking is causing differentiating behavior from npm runtime.

Minimal example would be

var a=2, b='2';

// Below lines does throws error in notebook
a==b

Also, I don't have much experience in Type-script, but is it okay if it shows different type-checking behavior based on context? For example switch-case types are matched only if it runs globally, but not when it executes in a function

Error when executing code in global context

image

While below code runs successfully when the similar switch-case logic in in a function

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants