Por qué SharePoint Framework sigue funcionando sobre React 17

Catorce versiones consecutivas de SharePoint Framework se han publicado con React 17.0.1. Catorce.

Parece estancamiento. No lo es, y rara vez se discute de otra manera.

Los hechos primero

Microsoft publica una tabla de compatibilidad para cada versión de SPFx. Esto es lo que dice sobre React, consultada el 5 de agosto de 2026 (compatibilidad de plataforma y toolchain de SPFx):

Tres versiones mayores de React en diez años de SPFx, y la actual se mantiene desde hace catorce versiones seguidas. La versión que lo cambió tiene fecha y es explícita: SPFx 1.16.0, publicada el 15 de noviembre de 2022, "SPFx ahora admite React 17 de forma predeterminada" (notas de la versión 1.16.0).

Una comparación lo hace más nítido. React 18 salió en marzo de 2022, ocho meses antes. Microsoft no eligió la versión más reciente y después se quedó atrás. Publicó una versión que ya estaba una generación por detrás el día en que llegó.

Sea lo que sea esto, nunca fue una apuesta por la novedad.

Sabemos lo que cuesta cambiar de versión mayor de React, porque ya ocurrió

La pregunta obvia es por qué tarda tanto. La respuesta está en las notas de la versión de la última vez que ocurrió.

SPFx 1.16.0 es la versión que llevó SharePoint de React 16 a React 17. Durante esa transición, Microsoft corrigió problemas que incluyen:

• extensiones de lista que fallaban por incompatibilidad de versión de React (#8482)
• errores de invalid hook call en elementos web (#8487)
• el panel de propiedades que no se mostraba (#8496)
• un error minificado de React, el #321 (#8510)

Son las notas de versión de la propia Microsoft. No es una queja de foro ni una anécdota.

Cambiar una versión mayor de React rompió código de clientes en producción, y las correcciones salieron junto al cambio que las causó.

La frase que cambia la historia

El roadmap de SPFx enumera versiones fechadas hasta septiembre de 2026. React 18 no está en ninguna de ellas. Está en una sección aparte llamada Top of Mind, sin versión y sin fecha, con este texto (roadmap de SPFx, consultado el 5 de agosto de 2026):

"Compatibilidad con React 18 para soluciones SPFx. Esta actualización depende de actualizar los elementos web y las experiencias proporcionadas por Microsoft a la versión React 18. Este trabajo está en curso."

Lea la dependencia otra vez, porque va en sentido contrario al que suele asumirse.

No son los clientes quienes esperan a que Microsoft termine una actualización de framework. Es Microsoft quien no puede ofrecer la actualización mientras sus propios elementos web no se muevan.

La superficie de la propia Microsoft es el bloqueo.

Cualquier organización con un elemento web a medida está aguas abajo de una migración interna que no ve, no influye y no planifica.

Leído junto con la sección anterior, el cuadro queda claro. Si pasar de 16 a 17 rompió extensiones de lista, paneles de propiedades y hooks en producción, la ausencia de fecha en el paso de 17 a 18 deja de parecer descuido y empieza a parecer una estimación acertada.

Esto no va de npm

Desde fuera, esto parece una actualización de dependencia. No lo es.

Lo que realmente tiene que sostenerse en el momento en que React cambia:

• los elementos web de la propia Microsoft, que se renderizan en cientos de millones de páginas que nadie va a probar una a una;
• Fluent UI, que los proyectos SPFx usan en v8 desde la 1.18 (usar Fluent UI en SPFx);
• todas las soluciones de clientes jamás instaladas, construidas contra un contrato de runtime que era cierto cuando se hicieron;
• el propio runtime, donde el código de Microsoft y el suyo comparten una página y una instancia de React.

Ese último punto es todo el problema. Una página de SharePoint no es una aplicación con un solo dueño. Es un runtime compartido donde el código de Microsoft y el suyo se ejecutan lado a lado, y una versión mayor de React no es un detalle de implementación privado cuando las dos mitades tienen que ponerse de acuerdo sobre ella.

React 17 ya no es solo una versión de framework en SharePoint. Se ha convertido en una dependencia de plataforma. Las dependencias de plataforma no se mueven cuando una de las partes está lista. Se mueven cuando lo están todas.

Por qué esto le afecta fuera de Microsoft

Todo lo anterior describe el desafío de Microsoft. Esta parte es la suya.

La restricción no se queda dentro de la plataforma. Aterriza en su repositorio, en la versión que instala, y en lo que su elemento web hace en una página que no controla.

El modo de fallo es el silencio

La página de compatibilidad de Microsoft incluye esta advertencia:

"Usar versiones incompatibles de React puede provocar fallos silenciosos en tiempo de ejecución, sin mensajes de error claros durante el proceso de compilación."

Y recomienda fijar la versión exacta:

npm install react@17.0.1 react-dom@17.0.1 --save-exact

Silenciosos es la palabra que importa. Una solución construida sobre React 18 compila. Se ejecuta en local. Pasa la revisión. Y después renderiza un área en blanco en producción, sin nada en la consola que lo explique.

No hay error que buscar, porque no hay ningún error. Si se lleva una sola instrucción de este artículo: fije exactamente la versión de React que indica su versión de SPFx, y compruébelo en revisión. No porque un React más nuevo sea peor, sino porque el runtime en el que va a desplegar ya ha decidido.

Lo que la IA cambia aquí, que es menos de lo que parece

Un agente escribe su elemento web en segundos. Escribe el JSX, las propiedades, los hooks y las pruebas, y lo hace bien.

Nada de eso es la restricción. La restricción es que una página tiene que cargar código de Microsoft y código de terceros en un mismo runtime y ambos tienen que funcionar. Ninguna cantidad de código generado hace que un ecosistema sea compatible consigo mismo, porque la compatibilidad no es un problema de escribir código. Es un acuerdo entre partes que publican en calendarios distintos, y una de ellas tiene cientos de millones de usuarios que nunca acordaron nada.

La IA escribe componentes. Las plataformas siguen teniendo que ponerse de acuerdo sobre el runtime.

Lo que no sabemos

Preferimos un "no lo sabemos" explícito a una suposición confiada que estará equivocada dentro de seis meses.

• Cuándo llega React 18. Microsoft dice que el trabajo está en curso y no da fecha. En el momento de escribir esto, el roadmap oficial de SharePoint Framework no asocia la compatibilidad con React 18 a ninguna versión de SPFx publicada ni planificada.
• Si el próximo paso es siquiera React 18. React ha seguido evolucionando desde la 17. Saltarse una versión es una estrategia legítima, y Microsoft no se ha pronunciado en ningún sentido. La pregunta interesante no es qué publicó React después, sino qué tiene que cambiar antes de que SharePoint Framework pueda acompañarlo.
• Cuánto de Microsoft 365 ya está migrado. "En curso" es toda la información pública.

La pregunta que hay debajo

La pregunta nunca fue por qué Microsoft sigue usando React 17.

El problema de Microsoft no es actualizar React. El problema de Microsoft es actualizar un ecosistema: una superficie propia, una biblioteca de componentes, un runtime compartido, y todas las soluciones que cualquier cliente haya instalado alguna vez, y todos ellos tienen que coincidir el mismo día.

Muchas organizaciones descubren que tienen exactamente el mismo problema. La dependencia es otra, el runtime es más pequeño y el público se mide en miles en lugar de cientos de millones, pero la forma es idéntica. Algo fundamental necesita cambiar, y la respuesta a "qué rompería eso" no está escrita en ninguna parte.

Si a una organización con los recursos de Microsoft le lleva más de cuatro años, vale la pena preguntarse qué tendría que moverse, y quién tendría que estar de acuerdo, antes de poder cambiar una dependencia fundamental en su propio patrimonio.

La mayoría de las organizaciones nunca lo ha contado. Esa suele ser la respuesta.

Por qué este artículo debe envejecer. Esperamos que SharePoint Framework acabe admitiendo una versión más reciente de React. Cuando eso ocurra, este artículo deja de tratar sobre React 17 y sigue tratando sobre otra cosa: por qué las dependencias de plataforma se mueven más despacio que las dependencias de una aplicación, y por qué eso es una propiedad de la plataforma y no un fallo de quienes la mantienen.

Si este tipo de análisis de ingeniería le resulta útil, la SharePoint Migration Field Guide sigue el mismo enfoque: primero las decisiones, después la documentación, marketing nunca. Escrito en inglés.