Breaking vscode into modules

[kmalakoff]

It's really great to see vscode's source released!

I've been look at your implementation of git and given the extensiveness of it, I was wondering if it could be a great, general purpose git wrapper around the CLI.

I spent a little bit of time trying to see what would be involved in extracting it into an npm module compiled into JavaScript (bear in mind I've never used typescript).

I ran into quite a few challenging problems:

1. typescript and module paths - it looks as if typescript handles modules very differently than node, brunch, webpack, ES6, etc. I've never used typescript before, but maybe they have some sort of global paths rather than relative paths or perhaps this was a choice by the vscode team? Ideally, all of the git implementation would be self-referencing using relative paths and depend on the smallest number of shared modules as needed using absolute paths to the node_modules folders / modules.

2. cross-dependencies into the vs directory - it looks like vscode was written in a semi-monolithic, but nicely grouped way rather than as many smaller modules. Ideally, there would be a separation between client, common, and node logic around smaller aspects rather than through the big platform and workbench buckets to reduce cross-dependencies and to promote reuse. When I'm trying to only compile an entry point through common/git/git.ts, it seems to be pulling in vs/base/browser/keyboardEvent.ts but I cannot figure out where the dependency is from (I'm new to typescript so not sure how to do dependency tracing).

These two aspects of code structure makes it difficult to separate the git functionality from all of the application logic so I'm putting aside this idea for now; however....I was wondering if there any plans to break up vscode into smaller, reusable modules using npm like Atom did?

Obviously, it is still early days for open sourcing vscode and I'm sure there are a lot of other things on your roadmap, but this would be a great longer-term goal!

[lusbuab]

Import paths in vscode are relative to the src/ directory. vs/base/browser/keyboardEvent.ts refers to src/vs/base/browser/keyboardEvent.ts.

[kmalakoff]

@flooooh I am looking for a way to use the git module outside of vscode, but also suggesting that the team consider breaking vscode into smaller, independent modules.

Like I mention, I am not very familiar with Typescript, but I am familiar with CommonJS, AMD, ES6 modules through years of experience using module loaders (Node, Brunch, Webpack, Babel / ES6, etc) so it looks like the way vscode has been implemented seems quite non-standard to me (eg, absolute paths). If you are going to break it up, relative paths within each module and absolute paths to node_modules is becoming / has become the standard, node and browser way to manage dependencies.

The reason I mentioned vs/base/browser/keyboardEvent.ts was it seems to be pulling in vs/base/browser/keyboardEvent.ts but I cannot figure out where the dependency is from. Today was the first day I've tried Typescript and the output was pretty unhelpful to figure out where that dependency was being pulled in from. Ideally, a compiler should include the stack trace of where the module was required from to help the user troubleshoot.

Let me know if the vscode team is considering breaking up vscode into modules!

[egamma]

The core of VS Code is implemented using AMD and not CommonJS. We do this so that we can bundle/package the files, which gives us performance and we do not plan to change this. So I'll have to close this issue.

[kmalakoff]

@egamma I'm assuming you can break apart an application into modules using an AMD-style loader since the main purpose of module loaders is to support modular code, right? Putting the module system choice aside for a moment..

By closing this, I would like to confirm that are you are making a definitive statement on behalf of the vscode team (not just a personal or single issue-focussed decision) that vsocde will not be open sourcing the various services and libraries as separate libraries. This is one of those questions that informs the community of the intentions of the vscode team regarding their recent open sourcing strategy.

Please consider this carefully since the benefits of modular code are enormous. What it would allow is that the open source community can use those "internal" modules to write plugins / extensions for vscode using the same libraries that you are using. By bundling modules into vscode in a monolithic pattern, you will be decreasing the "hackability" of vscode (using the Atom term).

PS. I'd like to write a GIT-based extension to vscode so I'd like this door to be open if possible.
PPS. I totally understand that a change like this will require a large amount of non-trivial refactoring which is why in my initial request, I focussed on whether this is a long term goal or not.

[egamma]

Notice we are already making several node modules available that were extracted from VS Code for extenders (e.g. https://www.npmjs.com/package/run-in-terminal). We will continue to do so I agree this is a good thing. However, we will do it on a case by case basis in an evolutionary way driven by scenarios.

I think it is a good idea to try to make some of the git services we provide as a node module. Please go ahead and give it a try.

[kmalakoff]

Thanks for confirming. That's great news!

I gave it a try for around 4 hours yesterday, but ran into the issues:

1. cross-dependencies from the git module into the vs codebase. As a quick and dirty approach, I tried to make the whole vs folder a node-module, but that's a lot of work for me to maintain and really doesn't solve the modularity problem.

2. troubleshooting dependencies in the git codebase on vscode UI libraries vs/base/browser/keyboardEvent.ts. Unfortunately, the TypeScript compiler didn't tell me where the dependency was coming from so after going in circles for around an hour, I gave up and submitted this issue. Ideally, the git module would be split between client and server code in separate modules (or perhaps the client code can stay within the vs folder) so consumers of the API can choose which pieces to use.

3. absolute paths within the application. I did a lot of search-and-replacing to make them relative within the git modules, but because TypeScript's turn around time on builds was very slow for me and with the debugging message problems in 2), I had to stop as well.

4. unfamiliarity with TypeScript. I spent 3 hours trying different approaches to compile the TypeScript to JavaScript (two webpack loaders, the typescript CLI, walking the typescript tree to compile all files, etc), but had to give up due to time constraints.

I really think the refactoring, tooling, and testing should be done by the vscode team since they will be able to structure things that way they believe is best. Also, I would like to see the libraries distributed as compiled JavaScript so that those of us who do not use TypeScript, do not need to add it to "hack it" into our tool chains when we run into these types of tooling problems.

There's no urgency on this for me and definitely agree on the evolutionary approach you propose, but I'll monitor this issue for progress so if you can re-open this issue so that it remains as a feature request, I would appreciate it.

PS. You might want to use git-server as a pilot for next step in your evolution 😉