question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Proposal: add native built-in typescript support

See original GitHub issue

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.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:71
  • Comments:36 (16 by maintainers)

github_iconTop GitHub Comments

19reactions
basaratcommented, Jul 6, 2018

I would love to remove the need for messing with plugins/index.js along with needing to install webpack @cypress/webpack-preprocessor typescript ts-loader

Current process https://github.com/basarat/typescript-book/blob/master/docs/testing/cypress.md

Ideally cypress ships with ts-node and all we (the users) need to do is npm install cypress typescript, write a tsconfig.json and start cracking with .spec.ts files 🌹

12reactions
ipzKellyRcommented, Jul 10, 2019

Would really appreciate Typescript just working out of the box. Especially commands.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Proposal: add native built-in typescript support · Issue #1859 ... - JOYK
Bundle in typescript as an official dependency in Cypress. Automatically parse all .ts file extensions for node files found in plugins , etc;...
Read more >
A Proposal For Type Syntax in JavaScript - TypeScript
Today we're excited to announce our support and collaboration on a new Stage 0 proposal to bring optional and erasable type syntax to ......
Read more >
TypeScript is working on a proposal to add built-in types in JS ...
TypeScript is working on a proposal to add built-in types in JS that are ignored at runtime. This is exactly what PHP should...
Read more >
Documentation - TypeScript 3.8
TypeScript 3.8 adds a new syntax for type-only imports and exports. ... TypeScript 3.8 brings support for ECMAScript's private fields, part of the...
Read more >
Goodbye Typescript, hello native typing for Javascript - DEV ...
The proposal. TC39 is the comity in charge of Javascript's specs - they help maintain and evolve the definition of JS. If you're...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found