Assets feature is silently ignored in libraries - should either fail or work

[zackdotcomputer]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

A minimum viable repro of this issue is available with further description here: https://github.com/zackdotcomputer/nest-libs-assets-repro

The issue here is as follows:

1. If I create a library, I can specify compilerOptions.assets for that library and this works as expected when building that library by itself.
2. However, if I use that library inside of an application, the library's assets options are silently ignored. The code for the library is incorporated into the application (i.e. even if you build the library separately to get assets working, you cannot then use that copy of the library) and the assets are not.

Describe the solution you'd like

At minimum, whatever is decided here should be noted on the pages documenting assets and libraries since currently there is no way of knowing about this limitation before developing for it.

As for an in-code resolution, any of the following options would, in my opinion, be satisfactory. My preference, however, is for number 3.

1. Fail the compilation if the user has specified assets inside of a library used by the application.

• Con: this would mean that builds might fail where they did not previously.
• Pros: this means fewer builds will appear to succeed but actually contain a behavior that is not the developer's intention (i.e. I suspect most users who specify assets inside of a library expect those assets to be incorporated in the built product, so the CLI should flag that that is not the case).

2. Include all assets in libraries inside of built applications. This would require having assets-manager.ts include all compilerOptions.assets-specified files into the output folders for application(s) built by nest build.

• Con: this might be overzealous - currently the assets manager cannot ascertain which libraries an application depends on so it may include assets that a given application does not actually require.
• Pro: this would enable users to define assets in libraries and use them in applications.

3. Allow an application's assets list to reference other libraries. This would entail a change to assets-manager.ts so that a reference could be made to libraries whose assets should be included. An example syntax might be "assets": { "libraries": ["images", "schemas"] }.

• Con: This requires an extension to the nest-cli.json schema and thus might be the largest lift in work.
• Pro: This is the best solution IMO because it does not change the default behavior but enables the desired behavior of being able to silo assets into reusable libraries.

Teachability, documentation, adoption, migration strategy

If my proposed solution (3) above were approved, I'd suggest that we separate the documentation of Assets from the Monorepo page where it currently is. We would then want to make the following two changes:

1. Expand the example section at top so that it's clearer how and where the assets object/array is being defined.
2. Add a new section title "Assets in Libraries" that explains how to specify dependencies on assets in libraries.

Solution 3 requires no direct migrations strategy because it does not change existing behavior. It only adds support for new functionality.

What is the motivation / use case for changing the behavior?

I had been attempting to use the existing assets feature in nest build to avoid having to make repetitive changes to the build pipelines for multiple applications produced by a single Nest monorepo. There are several assets in a shared library which must be included in the final output for each application. In this case they are the schema and client binaries for Prisma, which Nest's sample repo recommends adding item-by-item COPY statements for to one's Dockerfile, but the same principal applies to any such set of assets in a library which could be useful in multiple outputs.