-
-
Notifications
You must be signed in to change notification settings - Fork 230
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
Breaking Change: Rewrite repo in typescript, change tests to vitest, fix small bugs #300
Conversation
7641ffb
to
e5a4d56
Compare
I've done this with @philsturgeon for a few repos in the OpenAPI space. I'm also comfortable taking over as maintainer given #285 |
@@ -37,67 +41,68 @@ | |||
}, | |||
"license": "MIT", | |||
"funding": "https://github.com/sponsors/philsturgeon", | |||
"main": "lib/index.js", | |||
"typings": "lib/index.d.ts", | |||
"exports": { |
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.
Will this provide the same ES modules + CJS support that was added in #295? I don't want to annoy older users, but perhaps if we've raised the node version high enough then thats moot now anyway?
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.
Yes, I moved this back to being a cjs package. I also changed the pinned version from node experimental (17) to LTS (16). 14 will EOL in April so we should still support 16.
"@jsdevtools/host-environment": "^2.1.2", | ||
"@jsdevtools/karma-config": "^3.1.7", |
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.
Thank you, this is helping me deprecate those older @jsdevtools packages that were mainly used for APIDevTools packages. https://www.npmjs.com/package/@jsdevtools/karma-config
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 can remove the host-env one too, since the environment is always running in node.
From a user perspective is this is breaking change or is this a huge tech debt cleanup? We just released v10 so if its not a BC for the user then v10.1 would be good, but a v11 would be welcome if this is legitimately a breaking change. Also semantic release is all screwy so please make sure thats working before v11 or v12 is out. |
afe3610
to
37ec1dc
Compare
…x package versions
Pull Request Test Coverage Report for Build 4045129466
💛 - Coveralls |
@philsturgeon I think this should be a breaking change. While all tests pass this is a significant enough refactor I'd feel most comfortable with a major version bump. It also changes things like the required engine and dependency versions, and there might be weirdness in some peoples systems. I've tested it as thoroughly as I can think, but it doesn't feel like a 0.x bump |
Am I understanding that this bumped the repo to 9.1.1 as well? We have a breaking change in our code. We have had to go back to 9.0.9. Has this project moved to new maintainers? |
@coffeebe4code some changes from main snuck into 9.1.1 when I had to manually tag it due to semantic release going wonkier than I've ever known it to go. 9.1.2 solved the problem. That's not related to v10 or this PR. @jonluca fair enough, go for it. v11! @jamesmoschou tagging you in on this one. /fades away into the nearest bush. |
@jamesmoschou can you please take a look? Want to make sure this works + gets out before I work on the next set of PRs |
@jonluca what's the benefit of moving to yarn? I'm worried it will introduce another dependency for people. Whereas npm comes with node out of the box and I think has gotten a lot better since yarn originally came about. |
No real reason I suppose, I havent revisited npm since moving to yarn a few years ago and its my default for new projects. Happy to move back to npm if that's an issue though |
* @returns - The returned promise resolves with the parsed JSON schema object. | ||
*/ | ||
public parse(schema: RefParserSchema): Promise<JSONSchema>; | ||
public parse(schema: RefParserSchema, callback: SchemaCallback): Promise<void>; |
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've not done method overloading in TypeScript before. Do they all have to have the same return value, or should the variants with a callback return void instead of Promise?
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.
Well the types that are currently used in the repo are actually incorrect - all the function calls return a Promise, since it's an async function. This just types it correctly.
However, with this type-definition overloading, it's saying that when you pass in just schema
, the promise will resolve to a JSONSchema
, whereas if you pass in a callback the callback will be called and the promise will be void.
I don't really like the usage of arguments
in all these functions, and it would be nice to be able to write new APIs that actually do satisfy some of these apis. They're written in a very "accepting" way right now, IMO.
lib/ref.ts
Outdated
* @returns | ||
*/ | ||
static is$Ref(value: any): value is { $ref: string; length?: number } { | ||
return value && typeof value === "object" && typeof value.$ref === "string"; |
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.
This used to have an extra value.$ref.length > 0
check. Do we still need it?
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 dont think so but I'll add it back
* @param [options] | ||
* @returns - Returns the resolved value | ||
*/ | ||
get(path: string, options?: $RefParserOptions): JSONSchema4Type | JSONSchema6Type | JSONSchema7Type { |
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.
The return value here might not be JSON Schema. If this library is used on an OpenAPI document for example, it could be any one of these https://spec.openapis.org/oas/v3.1.0#components-object.
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.
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.
ahh you're right, sorry.
I only went through the lib files and had a few questions. I'm assuming the changes to .spec.ts files are just ts/prettier changes? Reading up a bit more, I think yarn is fine as it just affects contributors, Soo happy to get rid of Karma, it was an absolute pain. |
Also I'm wondering if we should sort out #303 first? |
Yes the spec changes are:
Contents of the tests are identical, with one added test And regarding #303 - I think this was an issue with moving to an esm + cjs build. This rewrite should work out of the box Here is a sample project with this new version where that example works properly. |
Thanks for clarifying my questions, happy to merge. Do we want to next version to be 10.1 or 11.0? I think you and @philsturgeon were discussing a major version bump? If so, I think semantic-release is going to deploy 10.1 as-is without a |
If we squash the commit won't it use the title of the PR? I could be mistaken, I'll push an update tomorrow morning if not |
Ahh, squashing will work. But it's more of a GitHub feature to use the PR name than the semantic-release feature approving! |
🎉 This PR is included in version 10.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Well shit, it was v10.1 anyway. LMK if I gotta nuke it from orbit. |
Ha I was wrong, no it's ok, we can keep it as is. I'll be making a few more PRs in the coming days so we can just move forward then |
I rewrote the repo in typescript and changed the testing scheme to use vitest. I also bumped some dependencies and removed others.
This is a pretty major refactor but all tests still pass.
I also undid the
type: module
and made the required node version the stable one (node 16) instead of 17.Important differences: