Adding types and fixing bugs on TypeScript implementation
eduardoleao052 opened this issue · comments
Changes necessary in the develop branch before merging into main:
- Adding types and fixing bugs of TypeScript implementation.
- Have zero errors pop up when running
npm run check. - Removing
tsconfig.jsonallowances before merging.
@eduardoleao052 i'll work on utils.ts btw.
@medic-code btw, I noticed that the tests got ~30% slower after the latest PR. Is that due to jest?
Mmm needs a bit of investigating, but the time taking in test running is mostly due to the last test, having played around with an initial jest setup, the first two tests take around 1-2 seconds which I think is acceptable, transformer test takes around 10seconds to complete. Do you happen to have the times prior to the PR for comparison (I'm using Macbook Pro m3 btw) ?
Couple of things that do stand out for me,
- These are most definitely integration tests which will take a longer time than unit tests, i think maybe some carefully placed mocks could help speed things up
- The tests are a little erratic as i've had a few runs of it and they've failed because the loss went above > 0.1 (The assertion is that loss should be less than or equal to 0.1) - should we have a slightly wider criteria for loss ?
After initially merging into develop, the Transformer test was taking around 6s, and it went to ~8s with jest. The others increased proportionally.
I don't think that's serious or anything, I'm just wondering if that's just due to the extra steps taken by jest or if the library got slightly slower in general. I'll test it out later.
And about the length of the tests: I think the loss threshold could be a little higher, yes. The transformer test taking longer is normal, as it is a model many times more complicated than the others, but I'll try to keep it to under 5s. Will get into it!
@medic-code found this online:
If you use TypeScript tests can take a bit longer since Jest will check types. Actually you can speed this up by skipping types checking. When you add ' { isolatedModules:true }' tests will run a bit faster. globalSetup will run every time you run 'npm run test'
Ok, sorry for spamming you :D
I just ran the tests without jest and some mock functions, and it's definitely not slower. It must be because of the may we're running jest incorrectly as of right now.
@medic-code I finished correcting all the TS errors. I think I also fixed the jest syntax, but I ask you to make sure I didn't do anything wrong lol
Thank you so much for the work here, the package has a much more professional look to it now!
Quick work on TS errors! Think the jest syntax looks fine. Good catch on type checking in jest.
I think there's definitely room for some unit tests in the future and maybe some refactoring of these three tests (not sure whether you'd call these e2e or integration) depending on future tests, extracting the neural net creation and some of the setup for example.
Got it! I'll look into that soon. But now the infrastructure is in place, so it will be easier to implement.
Thank you so much again! I think I'll merge this branch into main soon, but you have any other PRs you want to add, by all means go ahead!
Yep its good to have something basic in place to build from, go for it with the merge. If there's some improvements to tests + further tests I'll open up a PR.
Could you check @eduardoleao052 since merge into main, its still showing up TS errors in layers.ts,tensor.ts and utils.ts.
Also additionally, its still worth keeping the check script in package.json, although ESlint will pick up a lot of the types, it may not be configured to catch all typescript errors, we should allow the ability to check against typescript compiler.
@medic-code Mmmm, I'm almost sure no errors were popping up when I ran npm run check prior to pushing. Do you know the nature of those errors? I can't open the code right now, but will try to solve it later today. Thanks for pointing it out!
They're 99% about having any types (you can see this in 'tensor' class instance properties types in tensor.ts), there was around 230 before, so a good chunk has been done.
Got it. It's funny, because the tests even ran properly in the workflow.
What command did you execute to get this error message?
In the current updated code, i did a linting check (as the check script was removed in one of the commits)
Got it. Thanks again for pointing it out!
Please check in case something with my local repo is wrong. Btw with Husky and lint-staged, this wont be a problem as it will not make the commits/push whilst there are linting/type check errors.
That's great! I really forgot to use the npm run lint before pushing...
I'll check soon in my pc as well!
Quick question @medic-code. lint is asking me to correct some stuff like:
'_' is assigned a value but never usedUnexpected 'any'
But these are not exactly errors, or are they? Especially the first: I used the '_' as a variable that I would never use when unpacking an Array. But I imagine the idea is to correct all thatlintpoints out because that would mean better formated / actual TypeScript code. Is that right? (running tests and files normally, no error pops up, so that's why I ask)
Last question: lint is throwing 99% of its errors due to my type Array<any>. However, n-dimensional arrays are required for a library like this, so it could be an array of arrays of arrays (...). Is there any other way to represent that other than Array<Array<Array<Array<Array<number> | number> | number> | number> | number>?
I don't think I was being specific enough for which I apologise, no technically not errors of TS but using any essentially disables type checking and generally speaking we should try to use any very judiciously, there's usually a way to narrow this type down. If absolutely necessary you can use an unknown type which is safer from a typing perspective, if we don't know the type, it can't be passed around or operated on without typescript throwing an error or being narrowed down further by a type guard.
https://tannerdolby.com/writing/writing-safe-code-with-typescript/ - see here.
https://dmitripavlutin.com/typescript-unknown-vs-any/
Also if you haven't check out the TS-ESLINT docs here https://typescript-eslint.io/rules/no-explicit-any/
- If you are happy to have assigned but not used variables, you can change this ESlint rule - this is the flexibility of eslint. I have no preference for this really!
- There is a thing called conditional recursive types that can cover deeply nested arrays https://www.basedash.com/blog/guide-to-typescript-recursive-type - have to be a little careful with the nested data though.
Thank you for the answers! Makes sense, I'll try to finish solving these issues then.