[Feat]: use node-prune to remove all unnecessary files from the distribution

[pavelxdd]

What is your suggestion?

Currently in the code-server distribution archives there are over 56000 files, most of them are:

• READMEs
• CHANGELOGs
• LICENSEs
• TypeScript files
• C sources and headers
• Linter configs
• and so on...

I propose to use node-prune when building code-server to get rid of all unnecessary files.

Why do you want this feature?

To slim down the distribution size and for cleaneleness.

[jsjoeio]

Woah, I haven't heard about this before. That's a neat tool! I think we need to run some tests to make sure there are no negative side effects. Thank you for sharing! cc @code-asher you might find this cool.

[pavelxdd]

There's also yarn autoclean, but I didn't try it yet:
https://classic.yarnpkg.com/lang/en/docs/cli/autoclean/

[pavelxdd]

I've just tried yarn autoclean and it is more convenient, because no extra tool required, and you can set all cleaning patterns in .yarnclean file.

[jsjoeio]

Amazing! I guess next steps for us is to:

1. test yarn autoclean with code-server running in development aka yarn watch and make sure everything works
2. test with standalone release process

The only problem I forsee is we use yarn in development and npm with most release stuff so that could lead to some issues. I spent 2 days last week with yarn/npm issues 😂

[pavelxdd]

node-prune is the perfect middle ground if you don't want to handle npm/yarn issues.

It also supports modifying patterns via --exclude and --include flags, but there's no config file, so these options should be provided via command line arguments.

[jsjoeio]

Amazing! That sounds like the route we'd want to explore then.

[code-asher]

Neat! I think this sounds like a great idea. The only thing I would want to be careful of is removing source maps as they can make debugging production issues easier.

[code-asher]

Also we would need to keep the licenses probably.

[code-asher]

Revisited this and removing source maps would cut the size in half, might be good to get rid of those after all. I think we can still match up stack traces after the fact anyway.