-
Notifications
You must be signed in to change notification settings - Fork 7
feat: Autofix Core API (complex cases) #675
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
base: main
Are you sure you want to change the base?
Conversation
const potentialLibNamespace = node.text; | ||
|
||
// Check libs from the manifest | ||
const manifest = JSON.parse(this.manifestContent ?? "{}") as SAPJSONSchemaForWebApplicationManifestFile; |
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.
Can't we just re-use the existing logic that extracts manifest.json information instead of doing it again here?
(see
ui5-linter/src/linter/lintWorkspace.ts
Line 173 in 7b1e6dd
async function getLibraryDependenciesFromManifest(workspace: AbstractAdapter, virBasePath: string | undefined) { |
We could change this to a broader scope, like getInformationFromManifest
, and then returning an object with the relevant details.
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 just split the existing solution into separate PRs and now I'll do the refactorings
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.
Ah, sorry for the premature review 😄
|
||
if (manifestLibs[potentialLibNamespace]) { | ||
return true; | ||
} else if (manifest?.["sap.app"]?.id === potentialLibNamespace) { |
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 check should only be done when the project is a library.
0c07e32
to
cb85a25
Compare
56ebba1
to
66098d1
Compare
f67bfba
to
d4eed0f
Compare
08844d2
to
4ad1d98
Compare
f033503
to
0b46e18
Compare
18ec577
to
5015376
Compare
3360082
to
c815258
Compare
bcf4001
to
c0ed35a
Compare
JIRA: CPOUI5FOUNDATION-991 This is the first (base) chunk of several PRs related to the Core APIs autofix. All of the other PRs would build on top of it. Here we migrate the trivial cases where replacements are 1:1 Resolves partially: #619 Follow up PRs: #639 #675 --------- Co-authored-by: Max Reichmann <max.reichmann@sap.com>
c815258
to
1eafe45
Compare
Will be merged after: #662 |
9467ff9
to
c17665e
Compare
3fff6d0
to
6e4f54c
Compare
} | ||
return asyncOption; | ||
} else if (arg2?.kind === SyntaxKind.TrueKeyword) { | ||
if (ts.isStringLiteralLike(arg1)) { |
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.
What if it's not a string but an identifier? Shouldn't that be fine 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.
IMO, for the props in the allow list, any value is acceptable. Even if the library name
is concatenated or when the url
is calculated using e.g. sap.ui.require.toUrl()
or whatever.
Only for properties where we have to check for a certain value (e.g. async === true
) it makes sense to limit the values to something that we can evaluate.
|
||
if (ts.isPropertyAssignment(node) && ts.isIdentifier(node.name)) { | ||
const name = node.name.text; | ||
if (allowlistProps.includes(name) && ts.isStringLiteralLike(node.initializer)) { |
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.
Similar to my other comment, I guess we could also handle identifiers here?
Co-authored-by: Merlin Beutlberger <m.beutlberger@sap.com>
Co-authored-by: Merlin Beutlberger <m.beutlberger@sap.com>
Co-authored-by: Merlin Beutlberger <m.beutlberger@sap.com>
bde2a18
to
22580b2
Compare
JIRA: CPOUI5FOUNDATION-991
Enhances:
#671
#675
Enables
getLibraryResourceBundle
migration by checking whethersLibrary
(the first argument) is an actual SAPUI5 library. The check is performed as follows:libs
inmanifest.json
Reolves partially: #619