Plan for normalizing samples

[octref]

In the new API doc, sample is tightly integrated into the API docs:

• The HelloCode sample will be thoroughly illustrated in https://vscode-ext-docs.azurewebsites.net/api/get-started/your-first-extension.
• Extension Guides / Overview will have a listing of samples.
• Each Extension Guide will have an associated sample.

The samples become an important resource for people to explore VS Code API. We should try to make the samples

• More consistent.
• Closer to the HelloCode sample, which we suppose each Extension API reader will become familiar with.

This task is for you to update your sample to meet the Sample Guideline. It shouldn't take more than 20 minutes for you.

---

Please work on the ext-docs branch.
ext-docs branch has been merged to master. Work on master branch.

I did a PR to update the webview sample: #111. The sample and the Webview Guide tie nicely together now.

• completions-sample @jrieken
• decorator-sample @aeschli
• hellocode-minimal-sample @octref
• hellocode-sample @octref
• i18n-sample @dbaeumer
• lsp-log-streaming-sample @octref
• lsp-multi-server-sample @dbaeumer
• lsp-sample @octref
• task-provider-sample @dbaeumer
• terminal-sample @Tyriar
• theme-sample @sandy081
• tree-view-sample @sandy081
• webview-sample @mjbvz

---

Deferred: Please finish this during debt week.

• basic-multi-root-sample @bpasero
• configuration-sample @sandy081
• contentprovider-sample @jrieken
• extension-deps-sample @sandy081
• fsprovider-sample @bpasero
• diagnostic-related-information-sample @sandy081
• nodefs-provider-sample @bpasero
• progress-sample @bpasero
• quickinput-sample @chrmarti
• smart-template-strings-sample @jrieken
• statusbar-sample @jrieken
• vim-sample @alexandrudima
• webpack-sample @jrieken

[jrieken]

@octref Why do we use prettier and not our formatters? Apart from an extra config file, this looks like we are telling the world "Don't use our stuff"

[octref]

@jrieken

1. Your user config might have formatting configs, but I hope the formatter formats everything according to the workspace configuration.
2. Neither our formatter do not relate to https://github.com/vvakame/typescript-formatter, therefore users end up in a situation when they can't consistently format files in both editor + CLI.
3. tsfmt offers too much options and might turn new users away. It reads tsconfig, tslint config, editorconfig, vscodeconfig, and tsfmt.json. I don't want my formatting operation to be based on so many configs in a non-transparent way.

[jrieken]

Your user config might have formatting configs, but I hope the formatter formats everything according to the workspace configuration.

No, I use the default formatter options, e.g for TypeScript. Now prettifier makes TypeScript code look different then TypeScript makes it look and that's wrong if you ask me.

users end up in a situation when they can't consistently format files in both editor + CLI

These are samples right? Why would anyone want to format them from the CLI?

tsfmt offers too much options and might turn new users away.

You don't need tsfmt, just the default TypeScript settings that we ship with the tool

[octref]

No, I use the default formatter options, e.g for TypeScript. Now prettifier makes TypeScript code look different then TypeScript makes it look and that's wrong if you ask me.

I also have different opinions on code style...I think the goal of a sample repo is consistency in code style, and prettier enforces the same style much better than TS formatter in my experience.

These are samples right? Why would anyone want to format them from the CLI?

This allows me to run prettier --write **/*.{ts,json} to enforce styles through CI.
I already ran it through the TS/json files we have: 23674b2 and 154ad38.

You don't need tsfmt, just the default TypeScript settings that we ship with the tool

The only way to enforce style in local setting (as user might have changed his user-level TS formatting setting), is to replicate the whole set of typescript.format.* settings in .vscode and all my-sample/.vscode.

[octref]

@jrieken I dropped the formatter requirement for this milestone. Let's discuss later.
The new requirement is much more relaxed: no TS error and no TSLint error against these two rules:

{
	"rules": {
		"indent": [true, "tabs"],
		"semicolon": [true, "always"]
	}
}

I just did 3 LSP samples in 15 minutes. @Microsoft/vscode, if you are assigned for any samples, please take some time to update your samples. Otherwise, they will not end up in the listing on website and the README.

[jrieken]

I just did 3 LSP samples in 15 minutes

my problem is that I ended up more or less rewriting the sample cos I didn't like it anymore... still, the outcome is an improvement.

@octref in the ## VS Code API section really just a listing of functions that are used? should this include all types that are being used from the API without further explanation?

[octref]

my problem is that I ended up more or less rewriting the sample cos I didn't like it anymore... still, the outcome is an improvement.

The user would surely appreciate the update!

should this include all types that are being used from the API without further explanation?

I don’t want to list registerCommand for each sample. But if you do want to list all API calls that’s fine for me.