Adding in dev tooling to the contribution process

[MWhite-22]

PR for issue #39

Happy to walk through individual commits with more detail

[staaph]

remove nuxt here to keep it clean

[MWhite-22]

Its just a generic .gitignore that covers 90% of use cases. If it doesn't hurt anything I would rather keep it complete and easily extensible to other projects.

[staaph]

@nexxeln
move prettier to editorconfig ?
https://editorconfig.org/
// edit: just checked. vscode actually needs a plugin for it to work...

[MWhite-22]

@nexxeln move prettier to editorconfig ? https://editorconfig.org/

VSCode needs a plugin to work and I dont think this is a valid replacement for prettier (which works with eslint as well to prevent overriding rules re: styling)

[asrvd]

1. prettier -- it has been decided earlier that we don't need prettier either in the repository itself or in the generated project. see Prettier? #25 and fix pacakage manager logic #30
2. the same goes for eslint ig. @nexxeln your thoughts?
3. i personally don't know if we really need husky, let's see what others think about it

[MWhite-22]

1. The problem with not having a repo level prettier is that, as people contribute to the project, we will inevitably get a bloated git history of double quotes turning into single quotes, and vice versa, as well as other minor stylistic changes. If this project is expected to live on and grow as new technologies are integrated, setting a standard now, even if that standard changes, is a good idea IMO.
2. Eslint is a take it or leave it add on. Just something I thought would be a good idea as people of all skill levels and experiences start to add to the repo.
3. Husky is used here in the most simplistic way possible, by running a pre-commit lint-staged. If there's no testing being conducted, then we should lean on other tools like super strict type safety and linting, to get as confident as possible that the code functions as intended.

Again, all of these changes are just to help set a structure so that as the repo continues to grow in size, complexity, and quantity of contributors, an opinionated code standard can be maintained.

[MWhite-22]

1. prettier -- it has been decided earlier that we don't need prettier either in the repository itself or in the generated project. see Prettier? #25 and fix pacakage manager logic #30

Both of these issues are about having prettier in the template built by create-t3, not having prettier IN create-t3. This PR is specifically for this repo, not adding prettier or eslint into any created templates

[nexxeln]

I would've liked it if we had discussed all the tools before you made a PR 😄 .

Prettier Config

Please change single quotes to false

Eslint

This looks good to me

Changeset

I've never used or heard of this package, what exactly will it do?

Husky

I'm kind of 50/50 on this one. I would love to know what other people think.

[MWhite-22]

AFK for a few hours. Will push an update in a bit.

[MWhite-22]

Pushed new prettier config with double quotes.

Changesets is a way to update the package version, update a CHANGELOG.MD file, and push those changes through to NPM for package releases. Its just a tool I have used before with published packages.

pnpm changelog - starts and interactive CLI tool for collecting changes in a package and giving descriptions

pnpm version-packages - Propagates all those change descriptions into a "CHANGELOG.md" file, changes the version of package.json

Totally optional, but a nice tool if you're interested.

https://github.com/changesets/changesets

[nexxeln]

Pushed new prettier config with double quotes.

Thank you, please format the files also with the new config.

Changesets seems cool so why not, but the first time I'll use it I'll poke you with questions on Discord 😄.

[MWhite-22]

Already re-formatted!

Totally happy to jump in anytime.

[nexxeln]

Already re-formatted!

Oh lol sorry I didn't look at the commit.

I'm still unsure about husky.

[MWhite-22]

Totally happy to remove it if we need to. The current implementation just runs a lint and format before commit.

Without it, it's up to people to lint and format on their own, and although most IDEs have built in settings to do so on save, not everyone is going have the same setups and extensions.

This way we keep a relatively sane integrity check in the most "gentle" way possible.

[juliusmarminge]

I think it adds value as the amount of contributors grow.

Looking at commits and seeing a bunch of prettier-changes is annoying and makes it harder to see what the commit is actually doing.

What tool/setup to use for this I have no opinion on.

[nexxeln]

Okay let's do it then! I'll merge