-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[chore] prefer interfaces to types #2010
Conversation
🦋 Changeset detectedLatest commit: 9275aab The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
8068a47
to
c87236a
Compare
@benmccann The big difference here is that interfaces can be extended while types can't. So mostly user-customizable interfaces and internal types is mostly the right rule of thumb! |
@ignatiusmb you might be interested in this PR too given all the TypeScript stuff you've done. If it looks good to you or I don't hear anything I'll probably merge it in the next day or so |
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.
LGTM 👍
Following a heuristic, we can prefer to use interface
until we need to use features from type
.
I'm certainly no TS expert, but as I understand the only remaining difference in the latest TypeScript version is that Seems to me Again, no TS expert. |
I think interfaces give some flexibility when it comes to customization, being able to extend types without having to create new ones can be useful in some situations. |
For sure, in some situations. Just seems like a huge footgun. I see this as changing from My point was just that |
Yeah, but you can only extend an interface by redeclaring it (sort of), and if people take the time to redeclare an interface they usually know what they are doing |
…ePath * 'master' of https://github.com/sveltejs/kit: (85 commits) [chore] minor simplification of `parse_body` (sveltejs#2043) Version Packages (next) (sveltejs#2026) [chore] deduplicate config types (sveltejs#2030) [chore] remove invalid css declaration (sveltejs#2038) [fix] correctly pass Vite options in preview mode (sveltejs#2036) [feat] Ignore adapter build files (sveltejs#1924) [chore] Upgrade Rollup Don't check external links on prerender (sveltejs#1679) Version Packages (next) (sveltejs#2017) [chore] convert remaining type aliases (sveltejs#2018) [feat] explicitly set compilerOptions.hydratable to config.kit.hydrate (sveltejs#2024) [feat] More powerful and configurable rendering options (sveltejs#2008) [chore] typecheck example (sveltejs#2019) Change config `prerender.force` to `prerender.onError` (sveltejs#2007) [chore] prefer interfaces to types (sveltejs#2010) [docs] minor wording improvement in migration guide (sveltejs#2006) [chore] test debugging improvements [docs] fix typo (sveltejs#2003) [chore] use @ts-expect-error instead of @ts-ignore (sveltejs#1999) Version Packages (next) (sveltejs#1996) ...
I remember we had done this in Sapper. Makes sense to do it here too probably