[secuturitySolutions/detectionsResponse] Remove export* syntax from plugin index files #110903

spalger · 2021-09-01T20:50:31Z

See #57370 for reasoning, but the gist is that export * usage leads to unexpected and excessive exports from the plugin, leading the public API to grow and increasing the cost of maintaining backwards compatibility.

#109357 implements an ESLint rule to check for this that also assists in fixing the rule, though the auto-fix is imperfect and will require some manual review before committing.

Please remove the /* eslint-disable @kbn/eslint/no_export_all */ comment(s) added in #109357 from the relevant files, validate the auto-fix, remove unnecessary exports, and then submit a PR. Thank you!

Hint: You can search for the URL of this issue to find specific occurrences

The text was updated successfully, but these errors were encountered:

elasticmachine · 2021-09-01T20:50:32Z

Pinging @elastic/security-detections-response (Team:Detections and Resp)

## Summary See: #110903 This removes the `export *` from: * lists plugin This also adds `import type` and `export type` in a few areas and fixes the `LicenseType` by changing it from `server` to using the version from `common` to remove the restricted paths. This extra addition prevents more memory leaks when we run jest.

## Summary See: elastic#110903 This removes the `export *` from: * lists plugin This also adds `import type` and `export type` in a few areas and fixes the `LicenseType` by changing it from `server` to using the version from `common` to remove the restricted paths. This extra addition prevents more memory leaks when we run jest. # Conflicts: # x-pack/plugins/security_solution/public/types.ts

## Summary See: #110903 This removes the `export *` from: * lists plugin This also adds `import type` and `export type` in a few areas and fixes the `LicenseType` by changing it from `server` to using the version from `common` to remove the restricted paths. This extra addition prevents more memory leaks when we run jest. # Conflicts: # x-pack/plugins/security_solution/public/types.ts

…ule for security_solution plugin (#120188) ## Summary See: #110903 This removes the top level API `export *` spots from: * `security_solution` plugin by removing _all_ the exports from `security_solution/common/index.ts` since non of those were shared outside this plugin. Look at the metrics from the build below and you will see _huge_ drops off numbers across the board for required API documentation to the page load size. In the file `security_solution/common/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally it's best to import directly from their paths than expose the functions/types/etc... here. // You should _only_ expose functions/types/etc... that need to be shared with other plugins here. ``` But really I doubt we will have to share anything from `security_solutions` plugin to another plugin or expose it for anyone else. So I think this is 👍 the way forward to not expose anything directly from `security_solution/common/index.ts` anymore.

…ule for security_solution plugin (elastic#120188) ## Summary See: elastic#110903 This removes the top level API `export *` spots from: * `security_solution` plugin by removing _all_ the exports from `security_solution/common/index.ts` since non of those were shared outside this plugin. Look at the metrics from the build below and you will see _huge_ drops off numbers across the board for required API documentation to the page load size. In the file `security_solution/common/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally it's best to import directly from their paths than expose the functions/types/etc... here. // You should _only_ expose functions/types/etc... that need to be shared with other plugins here. ``` But really I doubt we will have to share anything from `security_solutions` plugin to another plugin or expose it for anyone else. So I think this is 👍 the way forward to not expose anything directly from `security_solution/common/index.ts` anymore.

…ule for security_solution plugin (#120188) (#120270) ## Summary See: #110903 This removes the top level API `export *` spots from: * `security_solution` plugin by removing _all_ the exports from `security_solution/common/index.ts` since non of those were shared outside this plugin. Look at the metrics from the build below and you will see _huge_ drops off numbers across the board for required API documentation to the page load size. In the file `security_solution/common/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally it's best to import directly from their paths than expose the functions/types/etc... here. // You should _only_ expose functions/types/etc... that need to be shared with other plugins here. ``` But really I doubt we will have to share anything from `security_solutions` plugin to another plugin or expose it for anyone else. So I think this is 👍 the way forward to not expose anything directly from `security_solution/common/index.ts` anymore.

…ule for cases plugin in the common section (#120310) ## Summary See: #110903, #120234 This removes as many top level API `export *` spots from: * `cases` plugin within the common section as we can. This reduces the number of metrics and warning about undocumented functions and reduces the page load size from `cases/common/index.ts`. Look at the metrics from the build below and you will see drop off numbers across the board for required API documentation to the page load size. In the file `cases/common/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such as kbn-cases-constants to share with // other plugins instead as packages are easier to break down and you do not have to carry the cost of extra plugin weight on // first download since the other plugins/areas of your code can directly pull from the package in their async imports. // For example, constants below could eventually be in a "kbn-cases-constants" instead. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` Some of those that are exposed such as `throwErrors` might actually be small simple mistakes as `security_solution` is using it but it has a "copy" of the same utility within just its server section rather than within its common section. That can be done in a different cleanup PR and cases team can decide what to do moving forward with their API before or post 8.0.0 release. For the metric increasing of: | id | [before](f01106c) | [after](f2e5d6a) | diff | | --- | --- | --- | --- | | `cases` | 16 | 22 | +6 | Running that suggestion: ```sh node --max-old-space-size=6096 scripts/build_api_docs --plugin cases --stats exports ``` I see this: <img width="1851" alt="Screen Shot 2021-12-03 at 9 30 45 AM" src="https://user-images.githubusercontent.com/1151048/144638952-43d50478-ea12-4ce1-8f73-585c735772b4.png"> I don't know if there is a way just yet to mark undocumented public API's but I don't feel concerned with it at the moment and if the case team wants to re-expose those or are going to support API's through documentation they can decide what to do. This PR is more about just removing as much as possible to start with and then go the other direction where the individual teams can decide what to expose and if the download weight is worth it or if it's just `export type` and holds no weight, etc...

…ule for cases plugin in the common section (elastic#120310) See: elastic#110903, elastic#120234 This removes as many top level API `export *` spots from: * `cases` plugin within the common section as we can. This reduces the number of metrics and warning about undocumented functions and reduces the page load size from `cases/common/index.ts`. Look at the metrics from the build below and you will see drop off numbers across the board for required API documentation to the page load size. In the file `cases/common/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such as kbn-cases-constants to share with // other plugins instead as packages are easier to break down and you do not have to carry the cost of extra plugin weight on // first download since the other plugins/areas of your code can directly pull from the package in their async imports. // For example, constants below could eventually be in a "kbn-cases-constants" instead. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` Some of those that are exposed such as `throwErrors` might actually be small simple mistakes as `security_solution` is using it but it has a "copy" of the same utility within just its server section rather than within its common section. That can be done in a different cleanup PR and cases team can decide what to do moving forward with their API before or post 8.0.0 release. For the metric increasing of: | id | [before](elastic@f01106c) | [after](elastic@f2e5d6a) | diff | | --- | --- | --- | --- | | `cases` | 16 | 22 | +6 | Running that suggestion: ```sh node --max-old-space-size=6096 scripts/build_api_docs --plugin cases --stats exports ``` I see this: <img width="1851" alt="Screen Shot 2021-12-03 at 9 30 45 AM" src="https://user-images.githubusercontent.com/1151048/144638952-43d50478-ea12-4ce1-8f73-585c735772b4.png"> I don't know if there is a way just yet to mark undocumented public API's but I don't feel concerned with it at the moment and if the case team wants to re-expose those or are going to support API's through documentation they can decide what to do. This PR is more about just removing as much as possible to start with and then go the other direction where the individual teams can decide what to expose and if the download weight is worth it or if it's just `export type` and holds no weight, etc...

…nter rule for cases plugin in the common section (#120559) * [Security Solutions] Removes tech debt of exporting all from linter rule for cases plugin in the common section (#120310) See: #110903, #120234 This removes as many top level API `export *` spots from: * `cases` plugin within the common section as we can. This reduces the number of metrics and warning about undocumented functions and reduces the page load size from `cases/common/index.ts`. Look at the metrics from the build below and you will see drop off numbers across the board for required API documentation to the page load size. In the file `cases/common/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such as kbn-cases-constants to share with // other plugins instead as packages are easier to break down and you do not have to carry the cost of extra plugin weight on // first download since the other plugins/areas of your code can directly pull from the package in their async imports. // For example, constants below could eventually be in a "kbn-cases-constants" instead. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` Some of those that are exposed such as `throwErrors` might actually be small simple mistakes as `security_solution` is using it but it has a "copy" of the same utility within just its server section rather than within its common section. That can be done in a different cleanup PR and cases team can decide what to do moving forward with their API before or post 8.0.0 release. For the metric increasing of: | id | [before](f01106c) | [after](f2e5d6a) | diff | | --- | --- | --- | --- | | `cases` | 16 | 22 | +6 | Running that suggestion: ```sh node --max-old-space-size=6096 scripts/build_api_docs --plugin cases --stats exports ``` I see this: <img width="1851" alt="Screen Shot 2021-12-03 at 9 30 45 AM" src="https://user-images.githubusercontent.com/1151048/144638952-43d50478-ea12-4ce1-8f73-585c735772b4.png"> I don't know if there is a way just yet to mark undocumented public API's but I don't feel concerned with it at the moment and if the case team wants to re-expose those or are going to support API's through documentation they can decide what to do. This PR is more about just removing as much as possible to start with and then go the other direction where the individual teams can decide what to expose and if the download weight is worth it or if it's just `export type` and holds no weight, etc... * Updated staged files * Fixed prettier issues

…ule for cases plugin in the server section (#120411) ## Summary See: #110903, #120234 This removes all the top level API `export *` spots from: * `cases` plugin within the server section This reduces the number of metrics and warning about undocumented functions. In the file `cases/server/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your functions to be exposed as public. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such to share with other plugins instead as packages // are easier to break down. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ```

…ule for cases plugin in the server section (elastic#120411) ## Summary See: elastic#110903, elastic#120234 This removes all the top level API `export *` spots from: * `cases` plugin within the server section This reduces the number of metrics and warning about undocumented functions. In the file `cases/server/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your functions to be exposed as public. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such to share with other plugins instead as packages // are easier to break down. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` # Conflicts: # x-pack/plugins/cases/server/client/alerts/get.ts # x-pack/plugins/cases/server/client/cases/update.ts # x-pack/plugins/cases/server/client/metrics/get_case_metrics.ts # x-pack/plugins/cases/server/client/sub_cases/client.ts # x-pack/plugins/cases/server/routes/api/utils.test.ts # x-pack/plugins/cases/server/routes/api/utils.ts

…ule for timeline plugin (#120437) ## Summary See: #110903 This removes all the top level API `export *` spots from: * `timeline` plugin within both the common and public section This reduces the number of metrics and warning about undocumented functions. I also add this text to timeline: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package to share with // other plugins instead as packages are easier to break down and you do not have to carry the cost of extra plugin weight on // first download since the other plugins/areas of your code can directly pull from the package in their async imports. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ```

…ule for cases plugin in the server section (#120411) (#120564) ## Summary See: #110903, #120234 This removes all the top level API `export *` spots from: * `cases` plugin within the server section This reduces the number of metrics and warning about undocumented functions. In the file `cases/server/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your functions to be exposed as public. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such to share with other plugins instead as packages // are easier to break down. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` # Conflicts: # x-pack/plugins/cases/server/client/alerts/get.ts # x-pack/plugins/cases/server/client/cases/update.ts # x-pack/plugins/cases/server/client/metrics/get_case_metrics.ts # x-pack/plugins/cases/server/client/sub_cases/client.ts # x-pack/plugins/cases/server/routes/api/utils.test.ts # x-pack/plugins/cases/server/routes/api/utils.ts Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

…ule for timeline plugin (elastic#120437) ## Summary See: elastic#110903 This removes all the top level API `export *` spots from: * `timeline` plugin within both the common and public section This reduces the number of metrics and warning about undocumented functions. I also add this text to timeline: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package to share with // other plugins instead as packages are easier to break down and you do not have to carry the cost of extra plugin weight on // first download since the other plugins/areas of your code can directly pull from the package in their async imports. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` # Conflicts: # x-pack/plugins/timelines/public/components/actions/timeline/cases/add_to_case_action.tsx

…ule for timeline plugin (#120437) (#120569) ## Summary See: #110903 This removes all the top level API `export *` spots from: * `timeline` plugin within both the common and public section This reduces the number of metrics and warning about undocumented functions. I also add this text to timeline: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package to share with // other plugins instead as packages are easier to break down and you do not have to carry the cost of extra plugin weight on // first download since the other plugins/areas of your code can directly pull from the package in their async imports. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` # Conflicts: # x-pack/plugins/timelines/public/components/actions/timeline/cases/add_to_case_action.tsx

## Summary See: #110903 This removes all the top level API `export *` spots from: * `metrics_entities` plugin within the server section This reduces the number of metrics and warning about undocumented functions. In the file `metrics_entites/server/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your functions to be exposed as public. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such to share with other plugins instead as packages // are easier to break down. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ```

## Summary See: elastic#110903 This removes all the top level API `export *` spots from: * `metrics_entities` plugin within the server section This reduces the number of metrics and warning about undocumented functions. In the file `metrics_entites/server/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your functions to be exposed as public. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such to share with other plugins instead as packages // are easier to break down. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ```

) ## Summary See: #110903 This removes all the top level API `export *` spots from: * `metrics_entities` plugin within the server section This reduces the number of metrics and warning about undocumented functions. In the file `metrics_entites/server/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your functions to be exposed as public. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such to share with other plugins instead as packages // are easier to break down. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>

## Summary See: elastic#110903 This removes the `export *` from: * lists plugin This also adds `import type` and `export type` in a few areas and fixes the `LicenseType` by changing it from `server` to using the version from `common` to remove the restricted paths. This extra addition prevents more memory leaks when we run jest.

…ule for security_solution plugin (elastic#120188) ## Summary See: elastic#110903 This removes the top level API `export *` spots from: * `security_solution` plugin by removing _all_ the exports from `security_solution/common/index.ts` since non of those were shared outside this plugin. Look at the metrics from the build below and you will see _huge_ drops off numbers across the board for required API documentation to the page load size. In the file `security_solution/common/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally it's best to import directly from their paths than expose the functions/types/etc... here. // You should _only_ expose functions/types/etc... that need to be shared with other plugins here. ``` But really I doubt we will have to share anything from `security_solutions` plugin to another plugin or expose it for anyone else. So I think this is 👍 the way forward to not expose anything directly from `security_solution/common/index.ts` anymore.

…ule for cases plugin in the common section (elastic#120310) ## Summary See: elastic#110903, elastic#120234 This removes as many top level API `export *` spots from: * `cases` plugin within the common section as we can. This reduces the number of metrics and warning about undocumented functions and reduces the page load size from `cases/common/index.ts`. Look at the metrics from the build below and you will see drop off numbers across the board for required API documentation to the page load size. In the file `cases/common/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such as kbn-cases-constants to share with // other plugins instead as packages are easier to break down and you do not have to carry the cost of extra plugin weight on // first download since the other plugins/areas of your code can directly pull from the package in their async imports. // For example, constants below could eventually be in a "kbn-cases-constants" instead. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ``` Some of those that are exposed such as `throwErrors` might actually be small simple mistakes as `security_solution` is using it but it has a "copy" of the same utility within just its server section rather than within its common section. That can be done in a different cleanup PR and cases team can decide what to do moving forward with their API before or post 8.0.0 release. For the metric increasing of: | id | [before](elastic@f01106c) | [after](elastic@f2e5d6a) | diff | | --- | --- | --- | --- | | `cases` | 16 | 22 | +6 | Running that suggestion: ```sh node --max-old-space-size=6096 scripts/build_api_docs --plugin cases --stats exports ``` I see this: <img width="1851" alt="Screen Shot 2021-12-03 at 9 30 45 AM" src="https://user-images.githubusercontent.com/1151048/144638952-43d50478-ea12-4ce1-8f73-585c735772b4.png"> I don't know if there is a way just yet to mark undocumented public API's but I don't feel concerned with it at the moment and if the case team wants to re-expose those or are going to support API's through documentation they can decide what to do. This PR is more about just removing as much as possible to start with and then go the other direction where the individual teams can decide what to expose and if the download weight is worth it or if it's just `export type` and holds no weight, etc...

…ule for cases plugin in the server section (elastic#120411) ## Summary See: elastic#110903, elastic#120234 This removes all the top level API `export *` spots from: * `cases` plugin within the server section This reduces the number of metrics and warning about undocumented functions. In the file `cases/server/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your functions to be exposed as public. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such to share with other plugins instead as packages // are easier to break down. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ```

…ule for timeline plugin (elastic#120437) ## Summary See: elastic#110903 This removes all the top level API `export *` spots from: * `timeline` plugin within both the common and public section This reduces the number of metrics and warning about undocumented functions. I also add this text to timeline: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your page bundle size to increase. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package to share with // other plugins instead as packages are easier to break down and you do not have to carry the cost of extra plugin weight on // first download since the other plugins/areas of your code can directly pull from the package in their async imports. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ```

## Summary See: elastic#110903 This removes all the top level API `export *` spots from: * `metrics_entities` plugin within the server section This reduces the number of metrics and warning about undocumented functions. In the file `metrics_entites/server/index.ts` I now put the advice of: ``` // Careful of exporting anything from this file as any file(s) you export here will cause your functions to be exposed as public. // If you're using functions/types/etc... internally or within integration tests it's best to import directly from their paths // than expose the functions/types/etc... here. You should _only_ expose functions/types/etc... that need to be shared with other plugins here. // When you do have to add things here you might want to consider creating a package such to share with other plugins instead as packages // are easier to break down. // See: https://docs.elastic.dev/kibana-dev-docs/key-concepts/platform-intro#public-plugin-api ```

spalger added chore Team:Detections and Resp Security Detection Response Team labels Sep 1, 2021

This was referenced Dec 1, 2021

[Security Solutions] Removes tech debt of exporting all from linter rule for lists plugin #120170

Merged

[Security Solutions] Removes tech debt of exporting all from linter rule for security_solution plugin #120188

Merged

cnasikas mentioned this issue Dec 2, 2021

[Cases] Remove export* syntax #120234

Closed

peluja1012 added the Team:Security Solution Platform Security Solution Platform Team label Dec 12, 2021

yctercero added Team:Detection Engine Security Solution Detection Engine Area and removed Team:Security Solution Platform Security Solution Platform Team labels May 14, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[secuturitySolutions/detectionsResponse] Remove export* syntax from plugin index files #110903

[secuturitySolutions/detectionsResponse] Remove export* syntax from plugin index files #110903

spalger commented Sep 1, 2021

elasticmachine commented Sep 1, 2021

[secuturitySolutions/detectionsResponse] Remove export* syntax from plugin index files #110903

[secuturitySolutions/detectionsResponse] Remove export* syntax from plugin index files #110903

Comments

spalger commented Sep 1, 2021

elasticmachine commented Sep 1, 2021