## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> This PR has been auto-generated.
> Do not attempt to push any changes unless you know what you are doing.
> Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
#### 1 plugin(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/screenshotting-plugin` |
`x-pack/platform/plugins/shared/screenshotting` |
<details>
<summary>Updated references</summary>
```
./docs/developer/plugin-list.asciidoc
./package.json
./packages/kbn-cli-dev-mode/src/watcher.ts
./packages/kbn-repo-packages/package-map.json
./packages/kbn-ts-projects/config-paths.json
./src/dev/code_coverage/ingest_coverage/__tests__/enumerate_patterns.test.js
./src/dev/precommit_hook/casing_check_config.js
./tsconfig.base.json
./x-pack/.gitignore
./x-pack/.i18nrc.json
./x-pack/platform/plugins/shared/screenshotting/README.md
./x-pack/platform/plugins/shared/screenshotting/jest.config.js
./x-pack/platform/plugins/shared/screenshotting/jest.integration.config.js
./x-pack/platform/plugins/shared/screenshotting/server/screenshots/screenshots.test.ts
./x-pack/plugins/lens/public/app_plugin/share_action.ts
./yarn.lock
```
</details>
<details>
<summary>Updated relative paths</summary>
```
x-pack/platform/plugins/shared/screenshotting/jest.config.js:10
x-pack/platform/plugins/shared/screenshotting/jest.integration.config.js:10
x-pack/platform/plugins/shared/screenshotting/server/formats/pdf/pdf_maker/worker_src_harness.js:14
x-pack/platform/plugins/shared/screenshotting/tsconfig.json:10
x-pack/platform/plugins/shared/screenshotting/tsconfig.json:14
x-pack/platform/plugins/shared/screenshotting/tsconfig.json:2
```
</details>
<details>
<summary>Script errors</summary>
```
```
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This is a follow-up to https://github.com/elastic/kibana/pull/184974
that updates the KB Entries API's (and underlying schema) to support
`IndexEntries` in addition to `DocumentEntries`. `IndexEntries` are
entries in the Knowledge Base that are not backed by an embedded raw
text source, but rather by an entire Index or Data Stream. The user can
set the data source name, the specific field to query (must be ELSER
embeddings in this initial implementation), and a description for when
the assistant should search this data source for Knowledge Base content.
This essentially enables the user to create custom retrieval tools
backed by their own data.
The changes in this PR, as with the other recent KB enhancements, are
behind the following feature flag:
```
xpack.securitySolution.enableExperimental:
- 'assistantKnowledgeBaseByDefault'
```
however as code change is required to test the new mappings. For this
you can update the `knowledgeBaseDataStream` in
`x-pack/plugins/elastic_assistant/server/ai_assistant_service/index.ts`
to
```ts
this.knowledgeBaseDataStream = this.createDataStream({
resource: 'knowledgeBase',
kibanaVersion: options.kibanaVersion,
fieldMap: knowledgeBaseFieldMapV2, // Update this to the V2 mapping
});
```
Change set includes:
- [X] ES Knowledge Base data stream schema and OAS has been updated to
support `IndexEntries`.
- [X] OAS schema files have been moved to the `/entries` sub-directory
- [ ] Backend KB services have been updated to support `IndexEntries`
- [X] Storage methods updated
- [ ] Retrieval methods updated (will round out these endpoint when
working the UI next)
---
With these API changes, I've also introduced a few sample `*.http` files
for easier development/testing. These files are supported out of the box
in JetBrains IDE's or in VSCode with the
[httpyac](https://httpyac.github.io/) (and many other) extensions. Since
the configuration for these files includes a `-` in the name, that's why
you'll see a few @elastic/kibana-operations files updated.
You can read more about `http` files
[here](https://www.jetbrains.com/help/webstorm/http-client-in-product-code-editor.html)
and for the spec see this repo
[here](https://github.com/JetBrains/http-request-in-editor-spec/blob/master/spec.md).
If we find these useful, we could add support to our [OpenAPI
Generator](https://openapi-generator.tech/docs/generators/jetbrains-http-client)
to create these automatically. They currently live co-located next to
the OAS and generated schema files here:
```
x-pack/packages/kbn-elastic-assistant-common/impl/schemas/knowledge_base/entries/bulk_crud_knowledge_base_entries_route.http
x-pack/packages/kbn-elastic-assistant-common/impl/schemas/knowledge_base/entries/crud_knowledge_base_entries_route.http
```
and the main config here:
```
x-pack/packages/kbn-elastic-assistant-common/env/http-client.env.json
```
The `x-pack/packages/kbn-elastic-assistant-common/.gitignore` has been
updated to ignore `http-client.private.env.json` files locally, which is
how you can override the config as you'd like. This is helpful to add
variables like `basePath` as below:
```
{
"dev": {
"basePath": "/kbn"
}
}
```
To use them, just open the corresponding `*.http` for the API you want
to test, and click `Send`, and the response will open in another tab.
Here is what that looks like for creating one of the new `IndexEntry` KB
documents that have been introduced in this PR:
<p align="center">
<img width="500"
src="https://github.com/user-attachments/assets/c9e70d1a-28d2-4eb3-9853-ab6d8e1c7acf"
/>
</p>
### Checklist
Delete any items that are not applicable to this PR.
- [X] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
* Feature currently behind feature flag. Documentation to be added
before flag is removed. Tracked in
https://github.com/elastic/security-docs/issues/5337
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR has breadth, but not depth. This adds 3 new `eslint` rules. The
first two protect against the use of code generated from strings (`eval`
and friends), which will not work client-side due to our CSP, and is not
something we wish to support server-side. The last rule aims to prevent
a subtle class of bugs, and to defend against a subset of prototype
pollution exploits:
- `no-new-func` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-new-func
- `no-implied-eval` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-implied-eval. Note that this
function implies that it prevents no-new-func, but I don't see [test
cases](https://github.com/eslint/eslint/blob/main/tests/lib/rules/no-implied-eval.js)
covering this behavior, so I think we should play it safe and enable
both rules.
- `no-prototype-builtins` to prevent accessing shadowed properties:
https://eslint.org/docs/latest/rules/no-prototype-builtins
In order to be compliant with `no-prototype-builtins`, I've migrated all
usages and variants of `Object.hasOwnProperty` to use the newer
[`Object.hasOwn`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn).
## Summary
*(Yeah, the title is pretty bad I apologize, I couldn't find something
sexy. OTOH, "sexy" and "logging" are usually antonyms, like "sport car"
and "fiat panda", or "server language" and "javascript")*
### 1. Provide a more developer-friendly alternative to
`Logger.isLevelEnabled`.
**With `isLevelEnabled`**
```ts
if(logger.isLevelEnabled('info')) {
const message = someExpensiveMessageProbablyBasedOnJsonStringifyOrSomething();
logger.info(message);
}
```
**With this PR:**
```ts
logger.info(() => someExpensiveMessageProbablyBasedOnJsonStringifyOrSomething());
```
### 2. Adapt calls to `log.debug` (arguably) costly to use this syntax
Aka any call relying on `JSON.stringify` or function calls.
I used the new syntax for those, except when the tests were too
complicated to fix or when the code did not allow it (e.g. untyped let
variables infered from return from assignations don't play well with
closures)
## Summary
Part of https://github.com/elastic/kibana/issues/7104
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
*Note: by default, enabling `http2` requires a valid `h2c`
configuration, meaning that it can only run over HTTPS with TLS1.2+*
```yaml
## kibana.yaml
server.protocol: http2
server.ssl.enabled: true
server.ssl.key: path/to/key
server.ssl.certificate: path/my/cerf
```
## What is this PR doing
### Add HTTP2 support for the Kibana server
#### - Plug http2 to the Kibana server
Even if HAPI was never officially updated to really support HTTP2,
node's `http`/`https`/`http2` modules are compatible enough to be able
to just instantiate an http2 server/listener and provide it to HAPI "as
a plain https listener". There were some tweaks to do (mostly silencing
a few warnings that HAPI was causing by sending http2-illegal headers
such as `Connection`), but overall, it went smoothly.
#### - Add config validation
By default, Kibana will require a valid `h2c` configuration to accept
enabling `http2`. It means that TLS must be enabled and that TLS1.2+
should at least be in the list of supported SSL protocols
(`server.ssl.supportedProtocols`). Note that default value of this
setting includes TLS1.2 and 1.3.
#### - Add escape hatch to run `h2` without `h2c`
In some situations, it may be required to enable http2 without a valid
`h2c` configuration. Kibana supports it, by setting
`server.http2.allowUnsecure` to `true`.
(*Note, however, that if http2 is enabled without TLS, ALPN protocol
negotiation won't work, meaning that most http2 agents/clients will fail
connecting unless they're explictly configured to use http2.*)
### Add documentation about this new feature
#### - Update the user-facing doc about this new `server.protocol`
setting
Update the user-facing Kibana settings documentation to include this
`http.protocol` setting (and refer to `server.http2.allowUnsecure`)
**Note: this setting, and this feature, are considered as experimental**
### Adapt our dev tooling to support running Kibana with http2 enabled
#### - Add a `--http2` flag to the dev CLI
Enabling this flag will add the proper configuration settings to run
Kibana with `http2` enabled in an (almost) valid `h2c` configutation.
*Note: when using this flag, even if listening on the same port, the
Kibana server will be accessible over https, meaning that you need to
use https in your browser to access it. Aka `http://localhost:5601`
won't work, you need to use `https://localhost:5601`. Also, we're using
the self-signed dev certificates, meaning that you must go though the
scary warning of your browser*
#### - Implement an http2-compatible base-path proxy
The current base path proxy is based on `hapi` and `hapi/h2o2`. I tried
for a bunch hours trying to hack around to make it work with http2
proxying, but ultimately gave up and implemented a new version from
scratch.
Note that with some additional efforts, this new http2 basepath proxy
could probably fully replace the existing one and be used for both http1
and http2 traffic, but it's an optimization / refactoring that did not
feel required for this PR.
### Adapt the FTR to run suites against http2
#### - Add support to run FTR test suite against an h2c-enabled Kibana
Note that with ALPN, clients using http1 should be (and are) able to
communicate with http2 Kibana, given h2c/alpn allows protocol
negitiation. So adapting our FTR tooling was not really about making it
work with http2 (which worked out of the box), but making it work with
**the self signed certifcates we use for https on dev mode**
Note that I'm not a big fan of what I had to do, however, realistically
this was the only possible approach if we want to run arbitrary test
suites with TLS/HTTP2 enabled without massively changing our FTR setup.
Operations and QA, feel free to chime in there, as this is your
territory.
#### - Change some FTR test suites to run against an HTTP2-enabled
server
I added a quick `configureHTTP2` helper function to take any "final" FTR
suite config and mutate it to enable `http2`. I then enabled it on a few
suites locally, to make sure the suites were passing correctly.
I kept two suites running with http2 enabled:
- the `console` oss functional tests
- the `home` oss functional tests
We could possibly enable it for more, but we need to figure out what
kind of strategy we want on that matter (see below)
## What is this pull request NOT doing
#### - Making sure everything works when HTTP2 is enabled
I navigated the applications quite a bit, and did not see anything
broken, however I obviously wasn't able to do a full coverage. Also, the
self-signed certificate was a huge pain to detect issues really caused
by http2 compared to issues because the local setup isn't valid `h2c`.
In theory though (famous last words) anything not doing http/1.1
specific hacks such as bfetch should work fine with http2, given that
even if using non-http2 clients, ALPN should just allow to fallback to
http/1.x (this part was tested)
#### - Enabling HTTP2 by default
PR isn't doing it for obvious reasons.
#### - Enabling HTTP2 for all FTR suites
First of all, it's not that easy, because it requires adapting various
parts of the config (and even some var env...), and we don't have any
proper way to override config "at the end". For instance, if you add the
http2 config on a top level config (e.g. the oss functional one that is
reuse by the whole world - learned the hard way), it won't work because
higher-level configs redefined (and override) the `browser` part of the
config, loosing the settings added to run the browser in insecure mode.
Secondly, I'm not sure we really need to run that many suites with http2
enabled. I learned working on that PR that we only have like one suite
where https is enabled for the Kibana server, and I feel like it could
be fine to have the same for http2. In theory it's just a protocol
change, unless parts of our apps (e.g. bfetch) are doing things that are
specific to http/1.1, switching to http2 should be an implementation
detail.
But I'd love to get @elastic/kibana-operations and @elastic/appex-qa
opinion on that one, given they have more expertise than I do on that
area.
- Running performances tests
We should absolutely run perf testing between http/1.1 over https and
http/2, to make sure that it goes into the right directly (at least in
term of user perceived speed), but I did not do it in the scope of this
PR (and @dmlemeshko is on PTO so... 😅)
## Release Note
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
Note: by default, enabling `http2` requires a valid `h2c` configuration,
meaning that it can only run over HTTPS with TLS1.2+
Please refer to the Kibana config documentation for more details.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/7104
Adapted from https://github.com/elastic/kibana/pull/183465
For `http2` support, we will have to change the way we configure the
HAPI server to manually provide the listener instead of passing down the
options for HAPI to create it.
This PR prepares that work, by creating the `http` or `https` (`tls`)
listener and passing it when creating the HAPI server instead of just
passing the `tls` options.
**Note:** no integration tests were added, because we already have the
right coverage for both tls and non-tls mode, so any change of behavior
introduced by the PR should be detectable by them.
## Summary
Related to https://github.com/elastic/kibana/issues/7104
Update supertest, superagent, and the corresponding type package, to
their latest version.
(of course, types had some signature changes and we're massively using
supertest in all our FTR suites so the whole Kibana multiverse has to
review it)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/177138
- Add a `http.payloadTimeout` configuration option, to control the
payload timeout
- Set the default value for this option to `20s` (was `10s` previously)
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
After https://github.com/elastic/kibana/pull/146212 it feels like the
babel-register cache is getting invalidated more frequently for some
reason. The current version of the cache only stores a single cache
entry for each file path, which shouldn't be too big of a problem but
with these changes several versions of a file will be cached. The
performance seems about equal, but because the cache contains multiple
versions of a single file we should spend less time transpiling files
when switching branches often.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR updates the core discovery logic to support loading plugins from
packages. This logic is additive, so that the existing plugins in the
repo and third-party plugins can continue to be loaded via the existing
mechanism, but with https://github.com/elastic/kibana/pull/148130 we
will be automatically migrating all plugins in the repo to packages,
which will use this logic.
The logic is already in-use in that PR, and was developed there, but
extracted here for easier review.
The logic is relatively simple, where a list of packages in the repo are
attached to the core `Env` and then filtered by core before converting
all plugin packages to `PluginWrapper`. The `PluginWrapper` still
exposes the plugin manifest to the rest of the code, and it is used in
many places, so rather than making changes to the `PluginWrapper` I'm
faking a legacy plugin manifest with the plugin package manifest.
@elastic/kibana-core: I'm going to need some help identifying what we
need to get test coverage for. This is a pretty simple addition to the
core IMO, and if it didn't work then nothing would work, so I'm pretty
confident in it, but would still appreciate your feedback.
This PR fixes the pattern matchers for `nonPackageMatcher` into our new
watcher logic as well as correctly classifies all the files found inside
the `screenshotting plugin`
After the recent changes to limit the dev-cli watcher to relevant
packages, the watcher started logging tons of unnecessary changes, and
in some cases breaking based on the state of the repo. I have seen this
happen with Chokidar before, and I'm not convinced we'll be able to fix
it, so instead I decided to swap it out with `@parcel/watcher`, which is
a conceptually simpler implementation that automatically batches changes
and watches an entire directory, rather than tons of unique
directories/files.
This new implementation is conceptually simpler, and because of the
design of the `@parcel/watcher` module I was pushed to reuse the
`RepoSourceClassifier` to determine if we should restart the server
based on a specific change. This means we now have a single source of
truth for test files and the like (the classifier will tell us if a file
is a test file, regardless of where it exists in the repo).
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR implements a linter like the TS Project linter, except for
packages in the repo. It does this by extracting the reusable bits from
the TS Project linter and reusing them for the project linter. The only
rule that exists for packages right now is that the "name" in the
package.json file matches the "id" in Kibana.jsonc. The goal is to use a
rule to migrate kibana.json files on the future.
Additionally, a new rule for validating the indentation of tsconfig.json
files was added.
Validating and fixing violations is what has triggered review by so many
teams, but we plan to treat those review requests as notifications of
the changes and not as blockers for merging.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
https://jestjs.io/blog/2022/04/25/jest-28https://jestjs.io/blog/2022/08/25/jest-29
- jest.useFakeTimers('legacy') -> jest.useFakeTimers({ legacyFakeTimers:
true });
- jest.useFakeTimers('modern'); -> jest.useFakeTimers();
- tests can either use promises or callbacks, but not both
- test runner jasmine is no longer included, switch all suites to
jest-circus
Co-authored-by: Andrew Tate <andrew.tate@elastic.co>
* [packages] add kibana.jsonc files
* auto-migrate to kibana.jsonc
* support interactive pkg id selection too
* remove old codeowners entry
* skip codeowners generation when .github/CODEOWNERS doesn't exist
* fall back to format validation if user is offline
* update question style
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* refact(NA): apply root_input_dir=src to each already created pkg
* refact(NA): update package generator
* fix(NA): correctly use rootDir
* fix(NA): use root input dir on latest introduced pkgs for jsts_transpiler macro
* chore(NA): merge with main
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [type-summarizer] reimplement for broader support
* Enable sourceMaps in all packages
* include naming collision in summarizePackage test
* fix readmes
* remove unnecessary transient dependency
* remove code that was commented out
* remove outdated todo comment
* ensure errors triggered by untyped-exports are ligible
* remove unused import
* break out snippet generation from AstIndexer
* refactor several massive files into smaller pieces and add more inline docs
* fix typos
* update jest snapshots
* add sections to readme that points people to the useful parts of the source code along with a high-level overview of how the type-summarizer works
* remove --dump flag, it doesn't work
* use decName instead of calling names.get a second time
* include `export` as invalid name
