I released my own Visual Studio Code Extension Pack and here is how you can too | Hacker News Reader

I released my own Visual Studio Code Extension Pack and here is how you can too

dev.to

33 pointslampe318 comments

You can add an "extensions.json" file inside of your workspace's .vscode directory with a list of recommended extensions[0]. The first time a new coworker joins the team, he only needs to pull the project and open it in VSCode, the editor will notice the file and prompt you to install the recommended extensions. The same thing can be done in the devcontainer.json file[1].

If you put the remote development extension in the "local" recommended, and the required extensions in the "remote" recommended, the requirements for the onboarding of a new team member boil down to "install VSCode, Docker and docker-compose"

[0] https://code.visualstudio.com/docs/editor/extension-gallery#...

[1] https://code.visualstudio.com/docs/remote/remote-overview

It takes very little effort to not say “he” and be more inclusive.

It takes less effort to not be offended

The parent might be a non-native speaker and might have a mother tongue in which nouns have genders - the co-worker in German is of male grammatical gender.

English is not my native language. In my native language (Italian) "coworker", like many other words, can be both male and female, but to avoid unnecessary redundancy our grammar allows for the male form to be used to include everyone with no distinction (even beyond the two default genders used in the grammar).

So, technically, my use of "he" was more inclusive than you realize.

> People forget what extensions they have installed

automatically sync your settings into a Gist with https://marketplace.visualstudio.com/items?itemName=Shan.cod...

bonus - if you work on multiple machines, it'll automatically update from one machine to the next too

You can also list them with `code --list-extensions` [0]

[0]: https://code.visualstudio.com/docs/editor/extension-gallery#...

One day I hope someone builds a VS Code distribution that comes as a 1-step setup as an IDE for "all" languages. So long as you have docker (or snap or whatever is favorable then) you can install a plugin and get LSPs, linters, code building, etc setup for "all" languages. Also autocomplete for things like proto/thrift files would be cool (by finding .proto and .thift files, running code gen, and indexing that in the language server).

One can dream...

Not sure why that would be useful to anyone. One of the benefits of vscode is how well it is architected, enabling users to customize the experience with nearly zero effort. This is primarily enabled via a rich extensions API.

It’s pretty obvious but to be clear, included support by default for all languages would degrade performance with little value to most users, since most users work only with a handful of languages.

Personally, I love that I can setup my default extensions that run across all projects/repos, then when I want to work in a language or use a tool not in my typical workflow, I can configure this with a few clicks or by updating a JSON file.

I'm not a vscode user, I just tried it once, but isn't it how it currently works? You open some file in a new language and then it istantly recommends you to install the relevant plugins with a click.

Bit offtopic. But I'm looking for extensios, that will allow me to set pernament filter on directories that are displayed in the explorer (sidebar). I quite often need to check some source file from node_modules and scrolling through all installed modules is painful. I wish I could filter those directories, like you can do in search (files to include/exclude).

Look for "Files: Exclude" within VSCode Settings.

Edit: additionally, the sidebar explorer now supports type-to-search.

Compared to Emacs extensions where you simply eval your new function and it becomes part of the editor this process is quite complicated.

Those who don't know Emacs can't really understand how quick it is to write extensions for emacs.

I wonder why VSCode could not replicate this simplicity instead of creating package.json files and stuff.

I have been quiet about this until now, and this will probably go against some grain here, but here is a question:

If emacs is so much more extensible, why is there so much better language support for mainstream languages in VSCode?

I couldn't find support for Angular with Typescript. Java support isn't anywhere near the big three (Netbeans, Eclipse and IntelliJ) and even the newcomer VSCode has decent Java support these days.

You'd think that the most extensible IDE with the smartest users should have support for most stuff one needs on a day to day basis?

What do you consider "better language support"?

Most emacs users are happy working at the level of "code with some completion", and generally don't want much more.

I write Java in emacs (Ive used netbeans and intellij quite a bit as well) and I cant say I've wanted anything that I dont have.

So... what might I want that you have found to not be available?

I triedVS Code and found it to be not as enjoyable as emacs. Sure, it makes some things easier, but emacs is light years ahead in functionality. I think most of the shortcomings could be addressed with a couple of projects.

> If emacs is so much more extensible, why is there so much better language support for mainstream languages in VSCode?

Writing language support like refactoring and stuff is a huge task, and emacs has a handful of volunteer maintainers, unlike the other tools you mention which have corporate backing behind them with programmers paid to add such support. So emacs could have the same level of support if companies would pay teams for years to develop such features.

But we have language servers now, because it became obvious there is no need to reimplement such support for every editor separately when a server can answer these requests.

Microsoft created LSP for Vscode, but it can be used by any other editor, and emacs too has language server support. I haven't tried it yet, but with LSP it can support the same language features as vscode.

Because it doesn't feel like an extension, so it doesn't feel serious.

There's also a difference between knowing emacs and knowing emacs. One can use it proficiently for years and still be completely taken by surprise when starting up unassuming ielm and slowly realising you have the complete superbly documented system at your fingertips, followed--indeed--by wondering why not everything that needs a (text)interface is written in emacs.

You are quite correct, but it's not obvious from the outset.

Reply on news.ycombinator.com