-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
wasp-config
userApi renaming
#2762
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
Conversation
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.
Pull Request Overview
This PR resolves the renaming inconsistencies by replacing references to "userApi" with "tsAppSpec" throughout the codebase, including source files and tests, to clarify the API’s public interface. Key changes include:
- Renaming imports, functions, and types (e.g. analyzeUserApp → analyzeApp, UserSpec → TsAppSpec) to reflect the new naming scheme.
- Updating mapping and re-export files as well as associated tests to use the new names.
- Adjusting internal symbols (e.g. GET_USER_SPEC → GET_TS_APP_SPEC) accordingly.
Reviewed Changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
waspc/packages/wasp-config/src/run.ts | Updated function name and import to use analyzeApp. |
waspc/packages/wasp-config/src/publicApi/tsAppSpec.ts | Renamed type from UserSpec to TsAppSpec and updated Crud type to CrudConfig. |
waspc/packages/wasp-config/src/publicApi/App.ts | Created a new App class that leverages TsAppSpec. |
waspc/packages/wasp-config/src/mapTsAppSpecToAppSpecDecls.ts | Adjusted mapping functions to use TsAppSpec types. |
waspc/packages/wasp-config/src/index.ts | Updated export paths to reflect the new public API structure. |
waspc/packages/wasp-config/src/appAnalyzer.ts | Renamed analyzeUserApp and adjusted instance checks to use the App from publicApi. |
waspc/packages/wasp-config/src/_private.ts | Updated symbol from GET_USER_SPEC to GET_TS_APP_SPEC. |
Various test files | Revised test references and helper functions to use the new TsAppSpec names. |
Comments suppressed due to low confidence (1)
waspc/packages/wasp-config/src/appAnalyzer.ts:10
- [nitpick] Consider renaming 'userAppResult' to 'appResult' to align with the new TsAppSpec naming convention and improve clarity.
const userAppResult = await getApp(waspTsSpecPath)
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 will let @sodic take a proper look, but I like the change in the naming, "user" is gone and names make sense! Nice stuff.
waspc/packages/wasp-config/__tests__/mapUserSpecToAppSpecDecls.integration.test.ts
Outdated
Show resolved
Hide resolved
@sodic tag to remind |
I will need to explore conflitcts |
…naming # Conflicts: # waspc/packages/wasp-config/__tests__/appAnalyzer.unit.test.ts # waspc/packages/wasp-config/__tests__/mapTsAppSpecToAppSpecDecls.integration.test.ts # waspc/packages/wasp-config/__tests__/mapTsAppSpecToAppSpecDecls.unit.test.ts # waspc/packages/wasp-config/__tests__/testFixtures.ts # waspc/packages/wasp-config/src/_private.ts # waspc/packages/wasp-config/src/appAnalyzer.ts # waspc/packages/wasp-config/src/index.ts # waspc/packages/wasp-config/src/mapTsAppSpecToAppSpecDecls.ts # waspc/packages/wasp-config/src/publicApi/tsAppSpec.ts # waspc/packages/wasp-config/src/run.ts
Deploying wasp-docs-on-main with
|
Latest commit: |
d644e22
|
Status: | ✅ Deploy successful! |
Preview URL: | https://d2d6a7bb.wasp-docs-on-main.pages.dev |
Branch Preview URL: | https://franjo-wasp-config-renaming.wasp-docs-on-main.pages.dev |
I recommend opening https://github.com/wasp-lang/wasp/pull/2762/files/0a624611038d5f42df918c3839295bd2780635d7 which shows state before merging Carlos's formatting changes. |
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.
Left some comments.
The new code is mostly ready, but we could improve the old stuff if you're up for it :)
Didn't add any type tests yet. Do we want that as another issue or here? |
Good question! I'll continue the discussion in the relevant thread: #2762 (comment)
Same thing here |
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.
Nice work with the tests. They make me much more secure in our generics.
I added some comments to them, mostly naming and descriptions.
type NoPropertiesObject = {}; | ||
|
||
type OptionalObject = { | ||
prop?: string; | ||
anotherProp?: number; | ||
}; | ||
|
||
type RequiredObject = Required<OptionalObject>; | ||
|
||
type OptionalNested<T> = { | ||
nested?: T; | ||
}; | ||
|
||
type RequiredNested<T> = Required<OptionalNested<T>>; |
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 names could also be more descriptive. I suggest:
ObjectWithRequiredPrimitiveProperties
ObjectWithOptionalPrimitiveProperties
ObjectWithNestedOptionalProperties
If we're using utility types, I recommend defining required variants and then adding in the optionality, not the other way around.
Finally, I'm not sure about NoPropertiesObject
. It does make sense in terms of the test, but looking just at its definition, the name is wrong. Like the comment says, {}
does not represent an object without properties. For example, this code would work:
const x: NoPropertiesObject = "something"
Which is problematic. So I suggest inlining {}
into the test.
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 changed tests themselves, so the type names no longer make sense.
If we're using utility types, I recommend defining required variants and then adding in the optionality, not the other way around.
For me there is no real difference, between going optional or required first, just that one is defined through the other. But I get the stance of having required object defined first. So I will change it.
For some reason, Partial
besides making field optional also allows for fields to be defined but with value of undefined.
This is the LSP information on hover:
type Partial<T> = { [P in keyof T]?: T[P] | undefined; }
While source code in lib.es5.d
shows:
type Partial<T> = {
[P in keyof T]?: T[P];
};
weird :D.
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.
For some reason, Partial besides making field optional also allows for fields to be defined but with value of undefined.
Yeah, this always confused me too. I don't know why that's the case.
These names could also be more descriptive
I still stand by this suggestion though, ObjectWithRequiredPrimitiveProperties
is better than RequiredObject
.
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.
Spotted some mistakes in tests, let's fix those.
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.
Nice work! Only three unresolved threads left.
I'm approving, but:
- We should definitely remove that export
- Please consider the other two threads as well
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 got nothing else to add. Nice work and thanks for the patience :)
Fixes: #2737
First draft for renaming.
userApi.ts
split intopublicApi/App.ts
andpublicApi/tsAppSpec.ts
Anything named
...userSpec...
renamed to...tsAppSpec...
.Anything named
...userApp...
renamed to...App...
(this referred topublicApi.App.ts
)Might be controversial:
added config suffix to
testFixtures.ts
config getters (so we havegetAppConfig
andcreateApp
)