You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SSR: Add a way to configure externalDependencies for the server bundle only with @angular-devkit/build-angular:application builder #26487
I would like to exclude some dependencies from being bundled but just for the server bundle. I can't find the proper way to do that using the @angular-devkit/build-angular:application builder.
Adding externalDependencies to the options prevent the packages from being bundled in both the browser and the server bundles.
Describe the solution you'd like
Maybe update the ssr option with an externalDependencies property that prevents the bundling just for the server.
Describe alternatives you've considered
Stop using the ssr option from @angular-devkit/build-angular:application and using a combination of the same with the @angular-devkit/build-angular:serverbuilder... but, I'm still trying to figure that out too 😅 .
Hi, thanks for the quick response! I'm trying to integrate opentelemetry in the server to get traces and metrics. The tooling for NodeJS assumes that the packages (express, pino, etc) are being loaded from node_modules (which is not a crazy assumption 😅) instead of coming from a bundle, to be able to provide automatic instrumentations.
I saw this issue that was also giving other reasons, but i think the resolution given there no longer applies.
You should be able to mark the relevant packages external such as express. This shouldn't cause any issues with the browser build since those packages shouldn't be used in a browser anyway.
Hi @clydin thanks for your input. I'm using your suggestion as a workaround, but I do think there are scenarios in which it is necessary to be able to mark externals for each bundle:
Scenario 1: Universal/Isomorphic packages
For example, let's think of an isomorphic/universal package like pino, it would be handy to exclude it from the server bundle and load it from node_modules and, at the same time, have it bundled for the browser.
Hey @frankswarm, appreciate the insights and scenarios. While I acknowledge their potential usefulness in certain situations, I feel these cases are somewhat uncommon.
Take Pino, for instance. Its reliance on the module being installed in node_modules seems more like a bug or limitation on their part. Bundling dependencies with node applications is a common practice nowadays.
Let's revisit this in the future, if it's something the community expresses interest in.
Activity
alan-agius4 commentedon Nov 24, 2023
What is the use-case case of having a dependency being external for the server but not for the browser bundle?
frankswarm commentedon Nov 24, 2023
Hi, thanks for the quick response! I'm trying to integrate opentelemetry in the server to get traces and metrics. The tooling for NodeJS assumes that the packages (express, pino, etc) are being loaded from node_modules (which is not a crazy assumption 😅) instead of coming from a bundle, to be able to provide automatic instrumentations.
I saw this issue that was also giving other reasons, but i think the resolution given there no longer applies.
clydin commentedon Nov 27, 2023
You should be able to mark the relevant packages external such as
express. This shouldn't cause any issues with the browser build since those packages shouldn't be used in a browser anyway.frankswarm commentedon Nov 28, 2023
Hi @clydin thanks for your input. I'm using your suggestion as a workaround, but I do think there are scenarios in which it is necessary to be able to mark externals for each bundle:
Scenario 1: Universal/Isomorphic packages
For example, let's think of an isomorphic/universal package like pino, it would be handy to exclude it from the server bundle and load it from node_modules and, at the same time, have it bundled for the browser.
Scenario 2: Browser only packages
Packages that are exclusively meant for the browser and are just bloating the server bundle like @opentelemetry/autoinstrumentations-web
alan-agius4 commentedon Dec 5, 2023
Hey @frankswarm, appreciate the insights and scenarios. While I acknowledge their potential usefulness in certain situations, I feel these cases are somewhat uncommon.
Take Pino, for instance. Its reliance on the module being installed in node_modules seems more like a bug or limitation on their part. Bundling dependencies with node applications is a common practice nowadays.
Let's revisit this in the future, if it's something the community expresses interest in.
angular-automatic-lock-bot commentedon Jan 5, 2024
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.