Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Feature Request]: Remove dependency on intl-messageformat

Abierto
#4,150 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@ernst-dev ya está trabajando en esto.

Desde el 22/7/2026.

  • #4758 de @ernst-dev — abierto
  • #5022 de @TrevorBurnham — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
react, typescript

Línea de trabajo

Start with the linked pull request #4758 and the draft branch, which demonstrate replacing intl-messageformat and changing the I18n.Provider messages type. Read the “Supporting additional locales” example in the internationalization documentation to understand the current raw-string usage and migration path. Done means the dependency is removed and users have a documented way to provide compiled messages; work is already underway in the open pull request.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement
Description

Cloudscape brings in intl-messageformat, which adds ~40KB to the minified JS bundle. But the built-in internationalization functionality doesn't use it. The dependency is only needed if users provide raw ICU strings to the messages property in I18n.Provider, as in the "Supporting additional locales" example here: https://cloudscape.design/get-started/for-developers/internationalization/#supporting-additional-locales

Using that dependency at runtime is an anti-pattern: Even for folks who need to add messages for additional locales, they should be compiling those messages at build time (like Cloudscape does for its own built-in locales) rather than making the browser do it.

I've drafted a branch that shows how the intl-messageformat dependency could be replaced: https://github.com/TrevorBurnham/cloudscape-components/tree/streamline-i18n-parser On that branch I've changed the TypeScript type of I18n.provider's messages prop so that it no longer accepts raw strings. That means that folks using that functionality would get a build-time error instead of a run-time failure. Combine that with a straightforward migration path away from those raw strings, and you'd have a nice easy performance win.

Code of Conduct
Lenguaje dominante
TypeScript
Estrellas
2.7k
Forks
248
Merge medio
3 d 14 h
PR fusionados (30 d)
83

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudscape-design/components

Todos los issues de cloudscape-design/components

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.