add typings for mocha #30190
add typings for mocha #30190
Conversation
💔 Build Failed |
|
@elastic/kibana-platform I am not sure if adding mocha types works like that? Jest typings already define a |
💔 Build Failed |
try to fix ci
💚 Build Succeeded |
| "target" | ||
| ] | ||
| } | ||
| { |
There was a problem hiding this comment.
This and the other config files were updated to use different line endings, please update your git config to preserve the line endings that were in the file: https://help.github.com/articles/dealing-with-line-endings/#global-settings-for-line-endings
There was a problem hiding this comment.
I also recommend installing the editorconfig plugin for your editor so it will automatically pickup configuration files like https://github.com/elastic/kibana/blob/master/.editorconfig
💚 Build Succeeded |
|
@vitalics comment here with a little bit more information about your local setup and I'll try to reproduce it locally to see how we can get those errors gone from your setup, but I'm 90% sure we don't need this unnecessary dependency and the tsconfig changes to accomplish it, so I'm closing this PR
|
|
Okay, seems like this is something we do need really soon, so lets go ahead and get this merged. |
💚 Build Succeeded |
spalger
dismissed
their stale review
Working to get this merged by using it in the kibana functional tests
💔 Build Failed |
| "extends": "../tsconfig.json", | ||
| "compilerOptions": { | ||
| "types": [ | ||
| "@kbn/test/types/expect.js", |
There was a problem hiding this comment.
@timroes the expect.js types from npm define a global expect variable, which I assume is important for some usages of the library, but is colliding poorly in the Kibana repo where expect.js and jest need to coexist. Since we are somewhat special in this regard and expect.js is effectively done, I copied the type definition into @kbn/test, changed it to a simple module type, and referenced it from the relevant config files. It won't have the same autoloading benefits of a @types/ package, but I think it's a suitable solution for the problem. Do you agree?
There was a problem hiding this comment.
I think that's a good behavior for now, and I currently don't see a reason why it should be bad.
💚 Build Succeeded |
💚 Build Succeeded |
| export default function ({ getService, loadTestFile }) { | ||
| import { FtrProviderContext } from '../../../types'; | ||
|
|
||
| // tslint:disable-next-line no-default-export |
There was a problem hiding this comment.
Could we perhaps disable this check completely for the function tests, since it's just the way the functional test framework has been build and even new test files will have to use that, so I think we should rather disable it in tslint for the test folder than to force every file to have that tslint disable in it, since I think an inline tslint-disable should be for exceptional cases, and ideally should go with a comment why it needs to be disabled there. This is not an exceptional case, but the expected behavior.
There was a problem hiding this comment.
Not really, tslint doesn't support overrides for patterns or anything like eslint does.
When https://github.com/typescript-eslint/typescript-eslint is ready and we move to it we will be able to, but until then this is our best option without dropping tslint.yaml files all over the place with I think is even worse. palantir/tslint#3447 (comment)
|
I suppose we need to close this PR since #31234 is already merged and closed |
…onfig files (#31948) In #31234 there were some extra changes that I've reverted, like use of the `tsconfig-paths` package to magically rewrite import statements to defy the standard node module resolution algorithm, the inclusion of several unnecessary options in the `test/tsconfig.json` file, and changes of the line-endings in the config files. This also brings a few enhancements from #30190 including a modularized version of the expect.js types, and options for explicit mappings for the PageObjects and services used in ftr tests.
…onfig files (elastic#31948) In elastic#31234 there were some extra changes that I've reverted, like use of the `tsconfig-paths` package to magically rewrite import statements to defy the standard node module resolution algorithm, the inclusion of several unnecessary options in the `test/tsconfig.json` file, and changes of the line-endings in the config files. This also brings a few enhancements from elastic#30190 including a modularized version of the expect.js types, and options for explicit mappings for the PageObjects and services used in ftr tests.
…onfig files (#31948) (#32250) In #31234 there were some extra changes that I've reverted, like use of the `tsconfig-paths` package to magically rewrite import statements to defy the standard node module resolution algorithm, the inclusion of several unnecessary options in the `test/tsconfig.json` file, and changes of the line-endings in the config files. This also brings a few enhancements from #30190 including a modularized version of the expect.js types, and options for explicit mappings for the PageObjects and services used in ftr tests.
…onfig files (elastic#31948) In elastic#31234 there were some extra changes that I've reverted, like use of the `tsconfig-paths` package to magically rewrite import statements to defy the standard node module resolution algorithm, the inclusion of several unnecessary options in the `test/tsconfig.json` file, and changes of the line-endings in the config files. This also brings a few enhancements from elastic#30190 including a modularized version of the expect.js types, and options for explicit mappings for the PageObjects and services used in ftr tests. # Conflicts: # src/functional_test_runner/lib/config/schema.js # test/common/services/es.ts # test/functional/page_objects/index.ts # test/functional/services/apps_menu.js # yarn.lock
…32827) * [ts] add script to verify that all ts is in a project (#32727) Based on #32705 We currently have TypeScript code that was backported to 7.0, which was backported without issue because it falls outside of any TypeScript projects in 7.0. This means that the pre-commit hooks break on changes to these files, and that they are not getting type checked by the type_check script. To fix this we need to verify that every typescript file in the repository is covered by a tsconfig.json file as part of CI. * tests typescript migration (#31234) * add typescript support for functional tests * [ts][ftr] improve types for ftr and expect.js, cleanup changes to tsconfig files (#31948) In #31234 there were some extra changes that I've reverted, like use of the `tsconfig-paths` package to magically rewrite import statements to defy the standard node module resolution algorithm, the inclusion of several unnecessary options in the `test/tsconfig.json` file, and changes of the line-endings in the config files. This also brings a few enhancements from #30190 including a modularized version of the expect.js types, and options for explicit mappings for the PageObjects and services used in ftr tests. # Conflicts: # src/functional_test_runner/lib/config/schema.js # test/common/services/es.ts # test/functional/page_objects/index.ts # test/functional/services/apps_menu.js # yarn.lock
Summary
Summarize your PR. If it involves visual changes include a screenshot or gif.
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.This was checked for cross-browser compatibility, including a check against IE11Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n supportDocumentation was added for features that require explanation or tutorialsUnit or functional tests were updated or added to match the most common scenariosThis was checked for keyboard-only and screenreader accessibilityFor maintainers