Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • gitlab-vscode-extension gitlab-vscode-extension
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 206
    • Issues 206
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 11
    • Merge requests 11
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • gitlab-vscode-extensiongitlab-vscode-extension
  • Issues
  • #204
Closed
Open
Issue created Jun 25, 2020 by Tomas Vik@viktomas5️⃣Maintainer

Migrate the extension to TypeScript

Problem to solve

The VS Code extension ecosystem is widely using TypeScript (TS), and VS Code itself is implemented in TS and exposes types for all its APIs. This issue is tracking the decision for migrating the codebase to TypeScript.

🍏 Benefits of using TS

  • Since there are no tests, the static type checking might help at the beginning with discovering bugs.
  • Future refactoring would be made simpler by the TS language support.
  • The extension implementation would be consistent with the ecosystem.
  • Community contributors can work on the extension without detailed knowledge of the codebase thanks to interface lookup and autocompletion.

🍎 Drawbacks of using TS

  • Effort connected with migration. That's mainly the following two parts:
    • Reviewing the !53 (closed) and potentially changing the TS implementation before merging
    • Manual testing and fixing any bugs that should come up from the rewrite.
  • The codebase will have a different syntax from what GitLab FE engineers are used to.
  • Compilation time is a drawback for Large TS codebases, it's not going to be an issue for the extension with its less than 10k lines of code.

Proposal

We need to decide as a team if the benefits outweigh the drawbacks. I propose we'll do it in a way of a RFC period of one week when we give the team chance to express their concerns or ideas.

If there are no serious concerns and we decide to proceed, we will review and merge the !53 (closed) in two distinct MRs.

The codebase is clearly separated in two:

  • the main extension lives in the project root /
  • the experimental webview1 lives in /src/webview and is compiled and exported in /src/webview/dist.

We would separate the !53 (closed) changes related to /src/webview and review and merge them first. That is a less risky change since the webview is experimental.

After that, we would review and merge the changes to the main extension.

Further details

You can have a look at the open MR from @massimeddu !53 (closed) to get a sense how would the initial TS version of the codebase look like.

Links / references

  • Discussion about using static type checking in the GitLab codebase: gitlab#19973 (moved)
  1. https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/tree/master#experimental-features ↩

Edited Jun 30, 2020 by Tomas Vik
Assignee
Assign to
Time tracking