Conversation
✅ Deploy Preview for advanced-astro-kit-i18n ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
I'm not against using Prettier, but I've been having annoying conflicts when using different languages, different repos, some with, some without prettier. Let's table this one for another time. |
|
hi, thanks for the reply, I've must missed it |
|
not sure what issues you had, but prettier can be used (and should be) to target only specific files and languages. And is pretty (uh uh pretty lol) much standard for javascript, as much as black is for python, they're not official but most people just adopt. Anyways, just my 2 cents |
Ports the tooling from PR #71 (closed/stale after its beta base branch was merged into main), plus adds a committed .vscode/settings.json so a contributor's personal VSCode formatter/prettier settings can't silently disagree with the repo's config: - .prettierrc / .prettierignore: format config (tabs, per user preference; 2-space tab width, LF, prettier-plugin-astro for .astro) - .editorconfig: editor-agnostic baseline (indent, charset, EOL, trailing whitespace) that also feeds Prettier's own defaults - .gitattributes: normalize line endings to LF at the git level - .vscode/settings.json: pins Prettier as the default formatter (including per-language overrides for .astro) and sets prettier.requireConfig so the extension always defers to this repo's config over a user's personal prettier.* settings; also un-ignores this file since it now needs to be shared, not personal - .vscode/extensions.json: recommend the Prettier extension - package.json: add format / format:check scripts and the new devDependencies - .github/workflows/format.yml: CI check for format:check on PRs and pushes to main No source files are reformatted yet in this commit; that follows as its own commit so this diff stays reviewable.
|
Hey @vasfvitor |
|
great! thanks for the credit |
2 participants
de79871 are the actual changes
also added 737c22d but is only worth if we actually hook as a branch rule to only merge if it pass, this way we ensure every PR is formatted and the codebase doesn't drift. If not then I'll remove it from the PR. First apply the rule to the beta branch, then later to the main branch once this version get released
the formatting config is just the default, most changes are from removing tabs and normalizing EOL to LF. Either if we don't and default to tabs, there will be lots of changes from adding tabs, right now the repo is mixed tabs and spaces. Personally I'd keep useTabs false
btw the reason format the codebase is to make it easier to review a PR, as you can see the actual changes in this PR are very small, but since I formatted almost every file you get those 109 files changed, we just need to enforce formatting to avoid it drifting.