docs: contributing.md

[brettearle]

Closes: #362

[changeset-bot]

⚠️ No Changeset found

Latest commit: 091b788

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-cli-549-svelte.vercel.app/

[brettearle]

1st draft @manuel3108 @AdrianGonz97 @benmccann

Could you please review and give feed back. What is missing? What needs more explanation? Is it how you want it style/voice wise? Mistakes? etc.

Does it need changeset section similar to sveltekit docs?

Testing conventions are not documented, could some one give me a run down of how you write your tests (dot point style, ill pull examples and things from code base once I know what good looks like)

Note: I am going through the migrate part in my next session

[pkg-pr-new]

Open in StackBlitz

npx https://pkg.pr.new/sveltejs/cli/sv@549

npx https://pkg.pr.new/sveltejs/cli/svelte-migrate@549

commit: 1b260ef

[manuel3108]

Thank you so much! This is very appreciated.

Is it how you want it style/voice wise?

I think this is a very good starting point. I think in the future we might be able to get a bit closer to the svelte and kit guides (at least the parts that apply). But that's non-blocking obviously, because everything is better than no contributing guide!

Does it need changeset section similar to sveltekit docs?

I would say yes, since this is crucial. We could also add there that changelogs should only be generated for sv and svelte-migrate since all other packages are bundled and not published.^

Testing conventions are not documented, could some one give me a run down of how you write your tests (dot point style, ill pull examples and things from code base once I know what good looks like)

I don't think we do have some real conventions at this point. Our testing coverage is not determined but probably very sparse. The only notable thing here might be that for each add-on we have integration tests setup, that actually install the deps, build the app, run the dev server and then run a few small snippets to see if the changes introduced by the add-on are working as expected.

Thank you so much for your help!

[manuel3108]

Actually, there is alos the pnpm dev command that I was about to run locally. It basically does the same as pnpm build but rebuilds the project once any related files change.

[brettearle]

Have Updated on that feed back. Thanks @manuel3108

[brettearle]

Have added change set command, and finished updates from feedback. Ready for second review.

[brettearle]

Updated. Thanks @benmccann

[manuel3108]

Apart from my two minor comments I think we should be good here. Thanks for your help!

[brettearle]

Thanks for all the feedback. Made this easy, appreciate it.