Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript 3.8 Iteration Plan #34898

Open
DanielRosenwasser opened this issue Nov 4, 2019 · 1 comment
Labels

Comments

@DanielRosenwasser
Copy link
Member

@DanielRosenwasser DanielRosenwasser commented Nov 4, 2019

This document outlines our focused tasks for TypeScript 3.8, as well as some of the discussion that explains how/why we prioritized certain work items. Nothing is set in stone, but we will strive to complete them in a reasonable timeframe.

Dates

Date Event
November 5th TypeScript 3.7 Release
January 3rd Create 3.8 Beta (3.8.0) Build for Testing
January 8th TypeScript 3.8 Beta Release
January 31st Create 3.8 RC (3.8.1) Build for Testing
February 4th TypeScript 3.8 RC Release
February 14th Create 3.8 Final (3.8.2) Build for Testing
February 18th TypeScript 3.8 Final Release 🚀

Work Items

Expected Work Items

Deferred Work Items

  • Interactive diagnostics

Planning Meeting Notes

Motivations

  • Bug backlog
  • Goals and current 6-month roadmap
  • GitHub user feedback (👍s)
  • Feedback from customer interviews, social media, past iteration plans
  • Visual Studio and Visual Studio Code feedback, as well as new functionality demands
  • Actionable PRs (need to make a call)

Notes

  • Compiler Features
    • New Export Forms
    • Top-Level Await
    • Private Fields (Flagged?)
    • Address anticipated feedback from 3.7
    • Lib Updates?
    • Declaration emit
      • UX
      • Performance
    • Bug Squashing!
      • Debt reduction for addressing bugs
      • Awareness of release
  • Performance
    • Investigate async file-writing
    • Plugin Investigation: async plugins?
    • Declaration emit
    • updateGraph details in TSServer responses
      • Provides easier analysis for TSServer performance problems.
      • Requires synchronization with editor teams.
    • Investigate recompilation speed
      • tsc --watch isn't as fast as gulp-tsb (because it's less accurate). Is there a fast and loose mode?
  • Tooling
    • dts-downlevel
      • Several library authors have explained that it is hard to support older versions of TypeScript while using the latest.
      • .d.ts files keep artifacts of your version of TS even when "uninteresting" for older versions of TS.
      • Goes back to long-standing request (e.g. readonly properties broke earlier versions of TS)
      • Enabled by typesVersions
    • Editor Productivity
      • Interactive diagnostics
        • Probably won't be able to prioritize during this release.
      • Investigate performance improvements
        • Cross-file go-to-definition
          • Noticed in partner team codebases
        • Request refactorings less often
      • Investigate automatic editor migrations
        • Do existing tools solve the problem?
        • Can we do a good job in the editor?
          • CD & App building
      • Leave room open to refactoring discoverability and triggers.
        • Refactorings without spans might need to be triggerable.
      • Refactorings
  • Infrastructure
    • Triage & Scheduling
    • Weekly Status Mails for Bug Reduction
    • JIT deoptimization analysis
      • VS Code extension
      • CI integration (e.g. @typescript-bot what deoptimizes?)
        • Will be learning here from general perf investigations. Not certain if this will be useful.
    • extendedDiagnostics diffs on PRs
    • GitHub Package Registry publishing for @types.
    • Expand version list for crash dumps
      • We should be looking at beta and RC.
  • Documentation
    • Handbook
    • Website
    • Contributing Guidelines
@mohsen1

This comment has been minimized.

Copy link

@mohsen1 mohsen1 commented Nov 12, 2019

I see "async?" for compiler plugins. That should be the case, at least for GraphQL. GraphQL type generation is currently async because it can be dependent on a network request to the API endpoint for introspection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.