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
web: fix client workspaces cicular dependency issue #44192
Conversation
Bundle size report 📦
Look at the Statoscope report for a full comparison between the commits 4b2936d and 6579bc4 or learn more. Open explanation
|
2630bb0
to
3cd6eda
Compare
3cd6eda
to
4b2936d
Compare
@@ -27,15 +25,6 @@ export interface Shape { | |||
right?: number | |||
} | |||
|
|||
export interface FetchFileParameters { |
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.
Moved FetchFileParameters
from the search-ui
package to the shared
package:
- To remove the circular dependency between
search-ui
andsearch
. - To colocate with the fetch function where this interface is required –
fetchHighlightedFileLineRanges
.
@@ -16,5 +16,6 @@ | |||
{ "path": "../branded" }, | |||
{ "path": "../http-client" }, | |||
{ "path": "../common" }, | |||
{ "path": "../observability-client" }, |
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.
Relying on Typescript project references makes it possible to avoid adding type declarations via the paths
property as we do in some tsocnfig.json
files.
@@ -6,7 +6,7 @@ | |||
"sourceRoot": "src", | |||
"baseUrl": ".", | |||
"paths": { | |||
"*": ["src/types/*", "*"], | |||
"*": ["../observability-client/src/types/*", "src/types/*", "*"], |
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.
My understanding of why it's required: the branded
package has observability-client
file in resolved modules, but because it doesn't rely on Typescript project references in some of the edges leading to observability-client
modules, they are resolved using this tsconfig.json
. The resolved modules graph doesn't have type definitions defined in the observability-client
package tsconfig.json
, so we need to manually add them here.
Even if we find the resolution path that leads from this package to observability-client
modules, it won't be possible to use the Typescript project references (that would remove the need to add type-declarations to paths
) because the shared
package is part of multiple circular import graphs, which are not allowed.
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.
Even if we find the resolution path that leads from this package to observability-client modules, it won't be possible to use the Typescript project references (that would remove the need to add type-declarations to paths) because the shared package is part of multiple circular import graphs, which are not allowed.
Hm but if we find it and eliminate the resolution path, do we still need to use the TypeScript project references? I’m thinking that ideally the branded
module does not know anything about observability-client
.
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, it should not know anything about it. We have many circular imports between packages, making it hard to analyze this structure and find specific resolution paths. We definitely should do it, but I'd love to have a plan first to ensure we won't regress after fixing the resolution graph.
(props.settingsCascade.final['search.contextLines'] as number | undefined) | ||
props.settingsCascade.final['search.contextLines'] |
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.
Auto-fixed by Typescript as a redundant type-casting.
Codenotify: Notifying subscribers in CODENOTIFY files for diff ef37174...4b2936d.
|
Codenotify: Notifying subscribers in OWNERS files for diff ef37174...4b2936d.
|
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.
In many cases, it's unclear why things should live in package X instead of Y. E.g., why was FetchFileParameters defined in the search-ui package?
Maybe this is just me but I think our package structure is a bit confusing. E.g I don't know what client/branded
is supposed to do that client/web
and client/shared
can't replicate? 🤔 Also what is the difference between client/shared
and client/common
.
@@ -6,7 +6,7 @@ | |||
"sourceRoot": "src", | |||
"baseUrl": ".", | |||
"paths": { | |||
"*": ["src/types/*", "*"], | |||
"*": ["../observability-client/src/types/*", "src/types/*", "*"], |
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.
Even if we find the resolution path that leads from this package to observability-client modules, it won't be possible to use the Typescript project references (that would remove the need to add type-declarations to paths) because the shared package is part of multiple circular import graphs, which are not allowed.
Hm but if we find it and eliminate the resolution path, do we still need to use the TypeScript project references? I’m thinking that ideally the branded
module does not know anything about observability-client
.
@philipp-spiess, I agree. I'll write a small RFC about that soon, so we can discuss it in the Google doc. |
@philipp-spiess have you checked the READMEs for
Does that make sense? |
@felixfbecker Thanks! This clears things up for me, yeah. |
Context
This PR removes a circular dependency between a couple of client packages to unblock Typescript builds. See more details in the inline comments.
Notes
A list of questions to address later in the documentation/RFC:
FetchFileParameters
defined in thesearch-ui
package?TODO
Test plan
App preview:
Check out the client app preview documentation to learn more.