refactor: branded types (2) #62
Conversation
Add branded type for reverse-domain-name. This showed a lot of cases where pkg-name type was used, where reverse-domain-name should have been used. Fixed these cases
Extends project tsconfig, but without emits
Rename to just domain-name since it should also work for regular domain names. Also it's a little shorter that way. The rules for what makes a valid name also changes a little bit. Now single segment names like just "com" are also valid. We don't need to do that much validation.
Add a builder function for making pkg-info objects for tests. Includes validation logic and auto-sets derived properties, such as also setting the package _id to the name
Builder does validation and allows for shorter test setups
Fix errors from passing strings to functions expecting domain names. Fix by using name fields from packages or asserting validity using "as"
The response object used by npm-registry-fetch is node-fetch Response, not request Response
Function acts on domain-types and so should be in a different file
Introduce package-url type which represents an url pointing to a package. Also add a few tests
Add type-checking for semantic-version strings. Currently not much validation
Package at specific version
There was a problem hiding this comment.
Since you have already defined some primitive type aliases, such as type Registry = string, refactoring to use branded types appears to be quite smooth.
One minor drawback is that, for every branded type, you will need to some helper methods, which makes a branded type feel like a sub-type derived from a primitive type, to which you can add constructor, parser, and validator methods. That makes the code a bit more verbose, but perhaps that is the trade-off you want.
Overall LGTM. See a few minor feedbacks below.
This is actually exactly what I want. For example
|
|
Notice that this refactor will not trigger a release by semantic release. Because the commit message is started with "refactor:...". However, your next PR which improves the parameter validation may trigger a release. |
|
This is fine. I would actually be very much fine with not having releases until I actually implement some new feature. Less stress in case i break something haha |
This is a copy of #61, but I messed up the commit history on that PR so I did it again with a clean rebase.
Introduce branded types for many of the simple types in the project. This has two primary effects/goals:
name@versionwas used where onlynameshould have been allowed etc.Tests were added for all new types.
This PR also includes some helpers for constructing
PkgInfoandPkgManifestobjects for tests, as well as some other minor changes.