V3 readme alt

[Rich-Harris]

Was thinking that with the compiler options etc living in the API docs now, maybe the README could just be this?

Ref #1953

[codecov-io]

Codecov Report

Merging #2436 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2436   +/-   ##
=======================================
  Coverage   91.83%   91.83%           
=======================================
  Files           1        1           
  Lines          49       49           
=======================================
  Hits           45       45           
  Misses          4        4

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5d71b51...4a79e37. Read the comment docs.

[Conduitry]

I think it makes sense to just have the compiler API live in one place, and the website is a better place for that than the readme.

I'm less sure about removing the build system plugins and the starter repos. Where is that stuff going to live? If we're going to make an effort to revive https://github.com/sveltejs/awesome, there might make sense.

I agree that talking about npm link doesn't belong here, but I do think we should mention the big main npm run scripts: just build, dev, and test probably.

The test directory could have its own readme honestly, explaining what the different types of tests are for, and about some of the finer points like -g and solo: true (and .solo in directory names) and the update.js scripts. This can happen separately though.

Maybe we could also have a link to the site directory and indicate that that's where the website lives.

Lastly, I'm not thrilled with the text logo at the top of the readme living off in githubusercontent.com somewhere. If it's used in a readme and it's not a badge or something else that needs to be dynamic, I think it should live in the repo.

[Rich-Harris]

All good points, have made a few changes.

I'm less sure about removing the build system plugins and the starter repos. Where is that stuff going to live? If we're going to make an effort to revive https://github.com/sveltejs/awesome, there might make sense.

I think that's a good idea. Though I have to admit that I find the whole 'awesome-xxx' thing incredibly grating — is it important to stick to that convention, or could we call it something like https://github.com/sveltejs/integrations, which feels a bit less 'participation trophy' and a bit more 'useful stuff for adults'?

[Conduitry]

Ha. I do appreciate some levity in my tech stuff, but I am glad that someone else finds the awesome-xxx thing grating. It's been driven so far into the ground that it doesn't feel remotely like levity anymore even, just another dumb cringe-inducing piece of bullshit tech culture. 😷

Anyway. Svelte is in a lot of ways about bucking conventions. I don't think we should worry about following this one. Having a repo that focuses on collecting integrations in one place (and without doing all of the other stuff that the awesome repo was trying to do) makes sense.

[tomcon]

agree 'awesome-xxx' should be passed by, but 'integrations' sounds a bit too tame imo
we need an attractive word somewhere inbetween both, here we go again, naming things is hard...

Perhaps use the same word as one of our channels:
Svelte Showcase?

[Conduitry]

I think there should just be a tame boring list of integrations somewhere, for things like build tool plugins, preprocessor plugins, editor extensions, etc. Having a showcase of cool stuff made with Svelte makes sense, but I think it should be separate.

[pngwn]

'quite-good'

[c0bra]

I personally have no problem with the awesome- prefix. It's my go to when looking for resources for some new tech I start looking at.

Maybe I've been lucky and haven't been hit with the negative side of it. But to me it's literally just a word.

[Rich-Harris]

I've moved sveltejs/awesome over to sveltejs/integrations so I'll merge this