Follow-up to issue: SSR: Add a way to configure externalDependencies for the server bundle only
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- build-system
Línea de trabajo
Start from the application-builder option definitions where externalDependencies is declared (schema and option resolution under packages/angular/build), then locate where the server and browser esbuild configurations diverge. Note the report that dev builds and prod builds are configured differently — both paths must apply the new option. Done looks like a server-only externalization option that is accepted, applied only to the server bundle (e.g. graphql external on server, bundled in browser), and verified with an SSR build; API naming needs maintainer sign-off first.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Command
build
Description
As title says, I'd like to follow-up on the unfortunately closed issue https://github.com/angular/angular-cli/issues/26487, requesting to configure externalDependencies independently for server and browser bundle.
Reading the mentioned issue, it has been closed because no particular value has been seen in being able to configure externalDependencies independently. However I'd like to point to a realistic and important case where such an option will be crucial.
Right now, we're still on using Webpack, which allows configuring externalDependencies explicitly for the server bundle, and that's the reason why it's not blocking us yet. But there's plans to eventually migrate to application-builder, however still a lot of obstacles ned to be solved, as like the mentioned lack of being able to define externalDependencies for server bundle only.
Our case is, we're using DataDog dd-trace for monitoring our server app infrastructure. dd-trace is being injected on runtime and requires all node packages doing downstream requests being external as otherwise it cannot properly trace them. See https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/nodejs/#bundling
In our particular scenario, this applies to graphql package. We had to externalize it, as otherwise we wouldn't get logs for all requests towards our GraphQL API on server-side. But on the client-side using the browser-bundle we do not want graphql package being external, as there's absolutely no reason in it.
So, our particular needs can be properly served by using Webpack builder but with the current options for application-builder this isn't possible.
As a workaround I tried to implement a custom Esbuild plugin, which should reset the external dependencies just for the browser build. But due to the Angular build architecture this only works for a prod build but not for a development build. So I eventually dropped this idea, which anyway doesn't seem clean.
Hence I'd highly appreciate if you could change your mind in considering separate externalDependencies configurations for server and browser build.
Describe the solution you'd like
Being able to configure externalDependencies separately for server and browser build.
Describe alternatives you've considered
No response
- Lenguaje dominante
- TypeScript
- Estrellas
- 27k
- Forks
- 11.8k
- Merge medio
- 1 d 2 min
- PR fusionados (30 d)
- 168
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de angular/angular-cli
-
Can't use an array of hostnames in --allowedHosts cli parameter in @angular/build:dev-serverAbiertoarea: @angular/build gemini-triaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
angular/angular-cli#33955 ·
Los mantenedores suelen responder en 1 día
-
area: @angular/cli gemini-triaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
angular/angular-cli#33055 · 1 comentario · 3 reacciones ·
Los mantenedores suelen responder en 1 día
-
dev-server: es2016 prebundle target for zone.js apps lowers private fields and breaks dependenciesAbiertoarea: @angular/build
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
angular/angular-cli#34280 ·
Los mantenedores suelen responder en 1 día
-
Vite dev server: proxy config normalization reorders glob keys, drops string `context` and misses URLs with a query stringPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertoarea: @angular/build
Dificultad 4/5 3-5 días Aptitud para principiantes 65/100
angular/angular-cli#34257 ·
Los mantenedores suelen responder en 1 día
-
Add CSP nonce to <link rel="stylesheet"> tags when ngCspNonce is setPosiblemente ocupada @alan-agius4 la tomó hace 3 días. Abiertoarea: @angular/build
Dificultad 2/5 1-3 horas Aptitud para principiantes 35/100
angular/angular-cli#34255 ·
Los mantenedores suelen responder en 1 día
Todos los issues de angular/angular-cli
Issues similares
-
bug priority:low ready-for-dev
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Automattic/data-liberation-agent#685 ·
Los mantenedores suelen responder en 1 día
-
Business
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
txn2/mcp-data-platform#2063 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 77/100
Crosstalk-Solutions/project-nomad#1427 ·
Los mantenedores suelen responder en 2 días