-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
Switch to typescript project references and incremental builds #46773
Comments
Pinging @elastic/kibana-operations |
I've tried to do this a couple times but it wasn't very easy, though I agree it's worth putting real effort into. |
This is unrelated to Kibana (I was Googling for Project References information), but when I try running I'm not sure, but I think that incremental builds are a default feature of Project References ( EDIT: Ah, yep! This is what I see in watch mode with
Note the "incremental" part. So, yeah, it is incremental by default. Cool! |
I did a quick (and dirty) spike to get incremental builds working for Kibana: #46772 |
@rudolf Could you measure the effect with TS built-in diagnostic tools https://github.com/microsoft/TypeScript/wiki/Performance#investigating-issues? |
Good idea! |
Pinging @elastic/kibana-platform (Team:Platform) |
Combined this issue with #72280 |
All tests done on #73924 with TS v4.0.2 Incremental buildshttps://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-flag
How it affects type build time of the OSS project:
We can conclude that it speeds up type check and build time if code hasn’t changed. Which is not the case for actively developed projects as Kibana. We could reduce scopes and make projects more focused - make every plugin a separate TS project at least for x-pack plugins, extract oss & x-pack tests in separate ts projects as well. @elastic/kibana-operations Do you envision any problems with this approach? Project referenceshttps://www.typescriptlang.org/docs/handbook/project-references.html |
Thank you so much for doing this research.
This is definitely what I hope we will do, though I don't think it will be easy. |
Ok, I'm going to start with a single plugin and a test project to see what problems we discover along the way. |
Today I had a stab at composite project integration Kibana repo. To make them work we should:
It requires starting from a leaf project with no dependencies. It would seem that the Kibana platform is an apparent candidate for this role. But it's not that simple, unfortunately:
|
There was a discussion about this topic when the core->data dependency was actually introduced. Don't exactly remember what the plan was though. @rudolf @elastic/kibana-app-arch does someone remember what our options were?
Let's see what operations have to say about this one, but moving at least the typedefs to core SGTM.
Lots of them should disappear with the legacy plugin discovery removal + legacy service. Most of the ones remaining should be imports of
Would have hoped that creating From a (very) quick look, it seems to be only from
However |
We opened an issue for this with a high-level plan forward here: #55485
+1
I wonder if we should just re-write this utility in Core and adapt the existing usages of it to this new test harness. I only see 18 usages of it, so I don't think it will be too difficult. |
My instinct is to decouple the core from the CLI rather than couple them further. It might be challenging because the CLI requires some config, so maybe we need to move it into core temporarily until we can decouple the CLI and keep it indenedent. |
My one concern is that allowing consumers to directly write the query predicates ends up leaking the way we map from a saved-object to the Elasticsearch document which represents it. This is the one benefit that we get from KQL, it's structured in such a manner that we can rewrite the query. For example, a consumer of the find API shouldn't need to know that we put everything under
you have to write
FWIW, we found a way around this by allowing Fleet endpoints to build the KQL manually and not parse it from a string #75693 |
WIP PR moving |
We added tooling, docs, and examples. Now it's up to the plugins to complete the migration. I created a migration meta issue #80508 and going to close the current one. Thanks to everyone involved! |
Developing Typescript with VSCode is currently frustratingly slow:
test
seems to be the slowest)I believe using [typescript references](https://www.typescriptlang.org/docs/handbook/project-references.html and incremental builds we should be able to make the build time much faster, have type errors show up without having to run
scripts/type_check
and improve type lookups and navigation in VSCode.The first iteration #72280
Steps
src/test_utils
to TS project Introduce TS incremental builds & move src/test_utils to TS project #76082src/core
to TS project Extract src/core in a separate TS project #76785src/plugins/kibana_utils
to TS project Add TS projects for src/plugins & x-pack/plugins #78440x-pack/plugins/licensing
to TS project Add TS projects for src/plugins & x-pack/plugins #78440The text was updated successfully, but these errors were encountered: