feature: setup merge #2
Conversation
* chore: upgrade next-intl to 4..6.0 - refactor the i18n folder with new architecture * feat: add formats to getRequestConfig return Co-authored-by: Copilot <[email protected]> --------- Co-authored-by: Copilot <[email protected]>
There was a problem hiding this comment.
@cfatrane
J'imagine que c'est dans ton template habituel, et c'est plus une question par curiosité : pourquoi garder un label en dur et le href des routes protégées ?
- avec le AppRouter la partie "protection" peut être gérée dans un layout
- le label sera remplacé par sa traduction
There was a problem hiding this comment.
D'autant que je vois que les routes protégées apparaissent encore à d'autres endroits
There was a problem hiding this comment.
Yes c'est un template que j'ai pas forcement mis a jour avec mes derniers projets et routing 😅, je le gère différemment sur mes vrais projets, on pourra le supprimer après. Celui que j'utilise dans mes projets et qu'on va aussi utiliser va importer les props de next-intl pour avoir des lien typé issue justement des pathnames dans routing.ts
There was a problem hiding this comment.
J'ai tendance à laisser les développeurs construire leur environnement qu'ils soient sur VSCode / WebStorm / Cursor, à voir ce que le reste de l'équipe préfère
There was a problem hiding this comment.
Yes ! C'est juste des recommandations mais le dev peut choisir de les ignorer, je verrais avec Antoine et Théo !
|
Merci @cfatrane ! Je t'ai fait quelques retours avant de merge, sens toi libre de les appliquer ou non |
ppernalon
left a comment
ppernalon
left a comment
There was a problem hiding this comment.
Quelques demandes notamment pour virer vercel qu'on n'utilisera pas a priori, monter en version Next et des petites questions concernant les routes protégées !
Encore merci 🙏
Yep c'est ce que je fais en general, d'ailleurs je desactive les autres options pour eviter de ne pas le faire par erreur, a voir avec les autres comment en configure ca |
This pull request introduces a comprehensive project setup for a Next.js application with strong support for code quality, formatting, localization, and developer tooling. The changes include configuration files for linting, formatting, commit conventions, testing, internationalization, and workspace recommendations, as well as initial localization message files.
The most important changes are:
Tooling and Code Quality Setup:
eslint.config.mjs) with support for Next.js, TypeScript, Jest, Tailwind CSS, and Prettier integration to enforce consistent code quality and style..prettierrc) with import sorting and Tailwind CSS plugin support for standardized code formatting..husky/commit-msg,.husky/pre-commit,.husky/.gitignore) for commit message linting and pre-commit checks, along with Commitlint configuration (commitlint.config.ts) to enforce conventional commit messages. [1] [2] [3] [4]Testing and Dependency Management:
jest.config.ts,jest.setup.ts) for unit testing with Next.js and Testing Library, and set up Dependabot (.github/dependabot.yml) for automated dependency updates. [1] [2] [3]Localization and Internationalization:
messages/en/home.json,messages/en/not-found.json,messages/fr/home.json,messages/fr/not-found.json). [1] [2] [3] [4]next.config.mjs) and type augmentation for locale and format support (global.ts). [1] [2]Developer Experience Enhancements:
.vscode/extensions.json) and settings (.vscode/settings.json) for a consistent development environment, including formatting, linting, and language support. [1] [2]components.jsonfor UI component and utility alias configuration, and.env.examplefor environment variable templates (Prisma/Supabase). [1] [2]