Overview

In 3.0.0 we had to include a dependency that automatically bundled in the typescript binary. This added some significant weight to the overall app size (35mb) which begs the question- why not just provide native support for typescript? We originally decided not to do this because of the added weight. Now that's no longer a reason. Additionally, support for typescript has continuously expanded, and as part of our overall philosophy of being zero-config, I think it's time to add support for it out of the box. We already have several dedicated doc guides for this.

As we're coming closer to bridging the gap between the browser + the node context shifts, it means that we also need to think about the plugin support for both of these contexts.

For instance we have file:preprocessor event, but this is really only for spec + support files going to the browser.

What if users want to write their plugins/index.js file using newer node features that the current version doesn't support? What if they want to write that file in typescript? What if they want to include or require other node files or lib code that also needs this?

Proposal

• Bundle in typescript as an official dependency in Cypress.
• Automatically parse all .ts file extensions for node files found in plugins, etc
• Automatically serve spec files with .ts extension
• Automatically find/use the same .tsconfig that your project would be using in node normally, but with a preference for .tsconfig files in cypress folder.
• Likely utilize ts-node to do typescript compilation on demand / in memory. Potentially do either transpileOnly or leave full blown type checking on.

Questions

• What if the bundled version of Typescript is newer/older than the one you have in your project? We should probably automatically try to require the one built into your project, and if none is installed fall back to ours.
• Perhaps we could accept a flag in cypress.json that prefers the bundled/native version of typescript even if a system/project typescript dependency was found
• How would users modify the ts-node options we use by default such as transpileOnly? We could add more cypress.json configuration options but then we're back to preferring static configuration vs configuration with code.

Concerns

Thinking about this more and looking at other frameworks. It is super nice to have Cypress "automatically" transpile things for you, because it has to work in both the node and browser environment. The problem is that customization is much harder. We have to expose to you the ability to modify the options. This worked well for the file:preprocessor plugin event - because the browser context is always executed later in the testing lifecycle. However, trying to do the same thing with node is not possible because there has to be some kind of entry point.

If we think about this outside of just Typescript we have the same issue. Imagine someone wanting to write their node plugin files using ES2018 - they'd have the same problem as they do whenever they're starting a vanilla node project for the first time. In both cases, you'd have to use babel to automatically transpile the .js or .mjs files on the fly. The difference is that it would be totally controllable by the user (we should just write some docs outlining this behavior). If you think about Typescript in this way you could argue that we should not add built in native support for it so that the user retains total control of both the node and browser context. On the other hand we could simply avoid adding lots of configuration options and instead just allow the user to turn off built in typescript support and then provide docs on how to manually wire things up in the case that you need to customize things beyond what we support.