-
Notifications
You must be signed in to change notification settings - Fork 38
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
Resolve typescript compilation problems #114
Conversation
"@edge-runtime/types": "^2.2.3", | ||
"@sinclair/typebox": "^0.28.15", | ||
"@types/web": "^0.0.99", | ||
"@sinclair/typebox": "^0.29.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typebox got a small bump to resolve an error on TS >5.1. I didn't bump all the way to latest because that caused problems with some major releases of TS 4.x.
type IndexList, | ||
type PartialIndexDescription, | ||
} from './listIndexes'; | ||
export { configureIndex } from './configureIndex'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These formatting changes don't read nearly as nice, but are necessary for compatibility with older versions of typescript.
src/utils/os.ts
Outdated
@@ -2,6 +2,8 @@ import * as os from 'os'; | |||
|
|||
export const getOSInfo = () => { | |||
// If available, capture information about the OS | |||
|
|||
// @ts-ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually deleting this file in a different PR, but TS 4.1 was upset that I was checking all these things in the if-statement that its knowledge of types told it should always be defined. Regardless of what the type says, i think it's prudent to be cautious regarding things you expect from the environment.
newResult.set(result); | ||
newResult.set(value, result.length); | ||
result = newResult; | ||
if (value) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Older TS compilers were erroring on the value.length
reference below because the type says value
could be undefined. I don't think it's a realistic case you would encounter in runtime, though due to the break on done condition above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work getting all these issues resolved so quickly. Overall this looks good, and thanks for walking through the thinking around the approach. I think explicitly covering variations in TS versions will be really helpful for us moving forward, especially given a lot of the feedback coming in post V1. 🚢
.gitignore
Outdated
scrap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I know this was in here before, but Is scrap
needed? I can't see how or where it'd be generated.
}, | ||
"types": "dist/index.d.ts", | ||
"files": [ | ||
"/dist" | ||
], | ||
"dependencies": { | ||
"@edge-runtime/jest-environment": "^2.3.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was looking at package.json
earlier and was questioning whether this should be in dependencies
or devDependencies
, nice.
cat package.json | ||
cat package-lock.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I'm assuming we want to keep these lines for debugging / visibility in the CI run output, but just in case they were leftover from debugging, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, my thinking was that it would be useful to be able to see what the commands actually installed. To speed debugging also in case of future failiures.
runs-on: ubuntu-latest | ||
strategy: | ||
fail-fast: false | ||
matrix: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise: It's a lot of overhead to validate against so many TS versions, but I feel like you've done a really elegant job here. Nice work.
2e93b54
to
3657da7
Compare
Problem
Several users have reported issues with typescript compilation
This PR addresses:
Solution
Clean up unused dependencies to resolve web-related type errors
I started by deleting dependencies and running tests to see what dependencies were no longer in use. I was able to delete these:
Removing
@types/web
seems to have resolved the majority of Typescript issues related to conflicts with web types inlib.dom.d.ts
. Since I was already in there mucking with dependencies, I went ahead and shuffled a few things between dependencies/devDependencies just to align with my current understanding of things.TS1005 (Typescript versions <=4.4)
People on older typescript versions report seeing many errors like this:
These errors were caused by using import statements that combined type and value imports onto one line. This syntax was evidently not supported in versions of typescript prior to 4.4.
Resolving these issues involved refactoring about 30 import statements along these lines:
Typebox errors (Typescript >= 5.1)
The
@sinclair/typebox
dependency is causing issues with very recent versions of typescript.New CI job:
typescript-compilation-tests
To verify this compilation issue doesn't come up again, I added a new github actions job along with a version matrix. It tests every major version of typescript back to version 4.1 (released fall 2020) along with a version of pinecone, then checks whether it can successfully
tsc
. I ran these with the v1.0.0 pinecone release to see the jobs fail as reported, then updated it to install the latest code in this branch and saw them pass. This will be part of CI for every PR from now on.Type of Change
Test Plan
Should see new compilation tests passing in CI. There are now 13 different checks running in CI to exercise compilation with major versions of TypeScript.
Follow-up
Probably we should add a lint rule to prevent us adding back any mixed type/value imports.