## Summary
Updates usage of `js-yaml` `load` and `dump` to `safeLoad` and
`safeDump`, in preparation for a major version update of dependency,
where the default behavior will be that of the safe function variants.
## Note to reviewers
`safeDump` will throw if it encounters invalid types (e.g. `undefined`),
whereas the `dump` function will still write the file including the
invalid types. This may have an affect within your use cases - if
throwing is not acceptable or is unhandled. To avoid this the
`skipInvalid` option can be used (see
https://github.com/nodeca/js-yaml#dump-object---options-) - this will
write the file, stripping out any invalid types from the input.
Please consider this when reviewing the changes to your code. If the
`skipInvalid` option is needed, please add it, or let us know to make
the change.
---------
Co-authored-by: Sid <siddharthmantri1@gmail.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
Co-authored-by: Elena Shostak <elena.shostak@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
## Summary
This PR overrides console functions only in production, in order to
sanitize input parameters for any potential calls made to the global
console from Kibana's dependencies.
This initial implementation overrides the `debug`, `error`, `info`,
`log`, `trace`, and `warn` functions, and only sanitizes string inputs.
Future updates may expand this to handle other types, or strings nested
in objects.
The unmodified console methods are now exposed internally in Kibana as
`unsafeConsole`. Where needed for formatting (log appenders, core
logger), calls to the global console have been replaced by
`unsafeConsole`. This PR also adds a new es linting rule to disallow
calls to `unsafeConsole` unless `eslint-disable-next-line
@kbn/eslint/no_unsafe_console` is used.
### Testing
Not sure how we could test this. The overrides are only enabled when
running in a true production environment (e.g. docker) by checking
`process.env.NODE_ENV`.
I was able to manually test by adding additional console output denoting
when the console functions were being overriden or not.
Closes https://github.com/elastic/kibana-team/issues/664Closes#176340
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* [eslint] add rule to prevent export* in plugin index files
* deduplicate export names for types/instances with the same name
* attempt to auto-fix duplicate exports too
* capture exported enums too
* enforce no_export_all for core too
* disable rule by default, allow opting-in for help fixing
* update tests
* reduce yarn.lock duplication
* add rule but no fixes
* disable all existing violations
* update api docs with new line numbers
* revert unnecessary changes to yarn.lock which only had drawbacks
* remove unnecessary eslint-disable
* rework codegen to split type exports and use babel to generate valid code
* check for "export types" deeply
* improve test by using fixtures
* add comments to some helper functions
* disable fix for namespace exports including types
* label all eslint-disable comments with related team-specific issue
* ensure that child exports of `export type` are always tracked as types
Co-authored-by: spalger <spalger@users.noreply.github.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* restrict import from core&plugin internals
* Fork import/no-restricted-paths and add allowSameFolder option
Our use case requires to restrict imports from plugin folders, which names are unknown for us yet. We cannot use 'import/no-restricted-paths' in the current state, because if we define 'from: plugins/*/server/' the rule will report all relative imports in the same folder as well. To fix this problem we added another option 'allowSameFolder' that makes the rule to ignore imports in the same folder.
* update notices
* add basePath option
* support glob pattern instead of reagexp
* remove @notice, make basePath required
* [@kbn/expect] "fork" expect.js into repo
* [eslint] autofix references to expect.js
* [tslint] autofix all expect.js imports
* now that expect.js is in strict mode, avoid reassigning fn.length
I'd like to add another custom eslint rule, but there isn't a very good place to do that right now. We have the `eslint-plugin-kibana-custom` package, which is super simple but isn't in the `@kbn` namespace and isn't included in the root eslint config, and `@kbn/eslint-plugin-license-header` is too specific, so I've merged those two packages into `@kbn/eslint-plugin-eslint`, which is a little redundant but allows is to refer to the rules within it as `@kbn/eslint/{rule}`, which feels nice.
Thoughts?
_**NOTE:**_ merging the eslint rules from the two packages means enabling prettier for the code from `@kbn/eslint-plugin-license-header`, all those changes are made in 42c7da6fe2. [View the changes without the prettier updates](b647f2b...74e07a0)
2019-03-22 17:12:14 -07:00
Renamed from packages/kbn-eslint-plugin-license-header/index.js (Browse further)
