You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a result of that issue, the webpack preprocessor for cypress will be removed, see: #2904
However, this causes the default setup to no longer support using typescript for the E2E spec files for cypress. The original discussion raised some alternatives to the problematic setup causing the issues the PR should solve. The details are mentioned below.
What does the proposed API look like?
There are two examples in the official cypress examples for using typescript.
Strictly speaking, there are three options to support typescript out of the box:
Using webpack
For the webpack version, there is a quite good documentation here: https://github.com/basarat/typescript-book/blob/master/docs/testing/cypress.md
It still uses the webpack-preprocessor for cypress.
Note that it suggest a very small webpack configuration, which also reduces the probability to cause any problems. In the current resp. previous setup, the full-featured webpack configuration with several loaders and plugins is resp. was used, which seems to be the cause of quite a lot of the problems raised on the issue tracker. Personally, I've had some success using the minimal webpack configuration, so this step seems to work in a general case.
On the other hand, it is quite problematic that the preprocessor uses some dependencies with fixed version numbers (most notably babel and webpack), which might lead to duplicates on package installation and thus even during runtime. Also, it requires a secondary - yet minimal - webpack configuration to be created and maintained.
Using browserify
The browserify version would use tsify (https://github.com/TypeStrong/tsify) to preprocess the spec files. Haven't tested this yet, though, but it seems to work quite good.
This version would have less conflicts regarding webpack, but still might cause problems with babel, which the preprocessor also uses with a fixed version. In addition, it'd be a different bundler to add as a dependency.
Using tsc directly
This would be more of a "barebone" version - usingtsc or the typescript API to transpile the spec files before they are used by cypress. Maybe spawn tsc --watch in parallel to cypress in dev mode, and use cypress-watch-preprocessor.
This should include some kind of helper script that cleans up the output folder when the task stops.
Alternatively, this might be turned into some kind of minimal preprocessor just involving tsc or the typescript API.
A downside would be that this might require a change or an addition to the file structure cypress generates by default so that the ts sources are not picked up. I'm not sure if there is a simple "ignore files" pattern for this purpose (there is ignoreTestFiles, but I'm not sure if it may cover this purpose.
General notes
All of the possible solutions mentioned above require a different typescript project to be configured that just covers the tests/e2e folder, while the root project has to exclude that folder.
It should be possible to implement all of the versions above without any breaking changes to the publicly accessible features of the cli plugin.
Personal note
The "barebone" version is quite attracting, considering that only a very minimal set of features is required. I'm not sure about the effort required to put this together in some kind of "barebone" preprocessor, but that'd be a very useful one. There are some examples about using the compiler API in the typescript wiki.
The text was updated successfully, but these errors were encountered:
I noticed this issue is from a while ago - is there any more recent update on this? Is there a current recommended way to use Cypress with TypeScript in a Vue app?
I am completely lost on how to use the combination of Vue + Typescript + Cypress. Seem that no matter what I try there is always some sort of issue. Either Cypress can not find files or headless is not working or something...
What problem does this feature solve?
Original discussion can be found here: #2903
As a result of that issue, the
webpack
preprocessor forcypress
will be removed, see: #2904However, this causes the default setup to no longer support using
typescript
for the E2E spec files forcypress
. The original discussion raised some alternatives to the problematic setup causing the issues the PR should solve. The details are mentioned below.What does the proposed API look like?
There are two examples in the official
cypress
examples for usingtypescript
.Webpack: https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/preprocessors__typescript-webpack
Browserify: https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/preprocessors__typescript-browserify
Strictly speaking, there are three options to support
typescript
out of the box:Using webpack
For the
webpack
version, there is a quite good documentation here: https://github.com/basarat/typescript-book/blob/master/docs/testing/cypress.mdIt still uses the
webpack-preprocessor
forcypress
.Note that it suggest a very small
webpack
configuration, which also reduces the probability to cause any problems. In the current resp. previous setup, the full-featuredwebpack
configuration with several loaders and plugins is resp. was used, which seems to be the cause of quite a lot of the problems raised on the issue tracker. Personally, I've had some success using the minimalwebpack
configuration, so this step seems to work in a general case.On the other hand, it is quite problematic that the preprocessor uses some dependencies with fixed version numbers (most notably
babel
andwebpack
), which might lead to duplicates on package installation and thus even during runtime. Also, it requires a secondary - yet minimal -webpack
configuration to be created and maintained.Using browserify
The
browserify
version would usetsify
(https://github.com/TypeStrong/tsify) to preprocess the spec files. Haven't tested this yet, though, but it seems to work quite good.This version would have less conflicts regarding
webpack
, but still might cause problems withbabel
, which the preprocessor also uses with a fixed version. In addition, it'd be a different bundler to add as a dependency.Using tsc directly
This would be more of a "barebone" version - using
tsc
or thetypescript
API to transpile the spec files before they are used bycypress
. Maybe spawntsc --watch
in parallel tocypress
in dev mode, and use cypress-watch-preprocessor.This should include some kind of helper script that cleans up the output folder when the task stops.
Alternatively, this might be turned into some kind of minimal preprocessor just involving
tsc
or thetypescript
API.A downside would be that this might require a change or an addition to the file structure
cypress
generates by default so that thets
sources are not picked up. I'm not sure if there is a simple "ignore files" pattern for this purpose (there isignoreTestFiles
, but I'm not sure if it may cover this purpose.General notes
typescript
project to be configured that just covers thetests/e2e
folder, while the root project has to exclude that folder.Personal note
The "barebone" version is quite attracting, considering that only a very minimal set of features is required. I'm not sure about the effort required to put this together in some kind of "barebone" preprocessor, but that'd be a very useful one. There are some examples about using the compiler API in the typescript wiki.
The text was updated successfully, but these errors were encountered: