Por qué importan las convenciones de nombres
Un proyecto con nombres inconsistentes se vuelve un caos cuando crece. En un equipo de 5 devs trabajando en React, si uno usa button.jsx, otro Button.js y otro ButtonComponent.tsx, perder tiempo buscando archivos se convierte en rutina diaria.
Las convenciones resuelven esto de raíz. React espera PascalCase porque cada componente es técnicamente una clase o función constructora. Vue permite ambos estilos pero la comunidad prefiere PascalCase para SFCs desde Vue 3. Angular impone kebab-case con sufijos obligatorios (.component.ts) porque el CLI lo genera así desde 2016.
Errores comunes: mezclar camelCase con kebab-case en el mismo proyecto, olvidar sufijos en Angular, usar .js cuando el proyecto es TypeScript puro, o nombrar index.tsx a todo (imposible debuggear stack traces). La regla de oro: un humano debe poder adivinar el framework solo viendo el nombre del archivo.
Estructura de archivos por framework
React no opina sobre estructura, pero la práctica ganadora es /components/Button/Button.tsx + Button.module.css + Button.test.tsx en la misma carpeta. Alternativa flat: /components/Button.tsx para proyectos chicos.
Angular sigue feature/button/button.component.ts + .html + .css + .spec.ts separados. Nunca mezcles lógica de features distintas en el mismo folder. Vue 3 prefiere /components/TheButton.vue (SFC único) con el prefijo 'The' para componentes singleton como TheHeader.
Next.js complica: /pages usa kebab-case automático (about-us.tsx → /about-us), pero /components puede ser PascalCase. Svelte recomienda PascalCase aunque el compilador acepta cualquier cosa. Web Components exigen kebab-case con guión (custom-button.js) por especificación HTML.
Sufijos y prefijos que comunican función
Sufijos clarifican responsabilidades sin abrir el archivo. .container.tsx indica lógica + estado, .view.tsx solo presentación. .controller.ts en Stimulus debe terminar con 'Controller' obligatorio. .page.tsx en Next.js 13+ va en /app con Server Components por default.
Prefijos también sirven: BaseButton.vue para componentes base del design system, AppHeader.tsx para componentes específicos de app (no reusables), TheSidebar.vue para singletons garantizados. Stripe usa StripeButton en su SDK para evitar colisiones de nombres.
En mobile, Flutter exige _widget.dart con underscore para privados, React Native usa .native.tsx vs .web.tsx para platform-specific, SwiftUI adopta View como sufijo obligatorio (ButtonView.swift). No inventes convenciones: seguí las del ecosistema o tu equipo odiará el code review.
Automatización y linters
ESLint con eslint-plugin-filename-rules fuerza convenciones: rechaza commits si ButtonComponent.tsx no matchea /^[A-Z][a-zA-Z]+\.tsx$/. Angular CLI genera todo correcto desde el vamos con ng generate component. Vue CLI hace lo mismo con vue create component.
Prettier no toca nombres de archivo, necesitás un hook de pre-commit. Husky + lint-staged puede correr un script custom que valide against tu convención. Ejemplo: si tu repo es React puro, cualquier .jsx debería ser .tsx o explotar CI.
Herramientas como plop.js generan componentes desde templates: corrés plop component Button y crea Button/index.ts + Button.tsx + Button.test.tsx con imports correctos. Nx workspace en monorepos fuerza estructura con generators predefinidos. Resultado: cero inconsistencias, onboarding de juniors en 1 día en lugar de 2 semanas.