Add ContextService to server#42395
Conversation
💔 Build Failed |
dfb5a90 to
0d62cd1
Compare
💔 Build Failed |
bd171bb to
46226a6
Compare
💚 Build Succeeded |
|
Pinging @elastic/kibana-platform |
💚 Build Succeeded |
src/core/server/plugins/types.ts
Outdated
There was a problem hiding this comment.
what is the main purpose of this file? as I understand it's to share types between client and server. PluginManifest exists on the server-side only, doesn't it?
There was a problem hiding this comment.
Right I made it for sharing types, but I figured I'd place all types for the plugins service in here for consistency.
There was a problem hiding this comment.
I figured I'd place all types for the plugins service in here for consistency.
ok. Although I'd rather keep them closer to the usage place. It helps us to track unused types and dependencies between different modules/files.
src/core/utils/context.test.ts
Outdated
There was a problem hiding this comment.
the problem of sharing server and client code popped up several times in this PR and in #39891
I'm wondering why we encourage domain-focus folder structure for plugins in favor of technology-focus but do not follow the same convention in the core? why not similarly structure core services?
- core
|__ context
|__ public
| |__ index.ts
|__ server
| |__ index.ts
|__ common/utils/ whatever you want
There was a problem hiding this comment.
That's not a bad idea. It could complicate some of the bundling / building logic, but I'd be interested in exploring that (in a separate PR / issue) if it helps alleviate this problem.
There was a problem hiding this comment.
could your create a separate issue to investigate this approach? we have to address problem of importing context from utils eventually.
1f36cab to
951d9bf
Compare
💔 Build Failed |
d804c75 to
bd4cd89
Compare
💚 Build Succeeded |
|
Removing dev_docs label to avoid duplicating the docs in #41251 |
Summary
This ports the ContextService (#41251) over to the Server side as well. No significant differences here, though the changes to the server-side PluginsService is slightly different, due to the way the backend does plugin discovery.
I split this into two commits.
utilsdirectory. This still doesn't feel like quite the right place, so I'm open to suggestions on this.