Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make "outDir" for assets more configurable (depth level?) #681

Open
raydaim opened this issue Apr 20, 2020 · 16 comments
Open

Make "outDir" for assets more configurable (depth level?) #681

raydaim opened this issue Apr 20, 2020 · 16 comments

Comments

@raydaim
Copy link

raydaim commented Apr 20, 2020

I'm submitting a...


[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Asset are not being copied dist folder if they are included in a library folder (even when they are added to the nest-cli.json)

Expected behavior

assets should be always copied to dist if the file type / folder pattern is included in the nest-cli.json

Minimal reproduction of the problem with instructions

https://github.com/raydaim/NestTest

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

Cannot include assets with libraries such as fonts / css files ...

Environment



[System Information]
OS Version     : macOS Catalina
NodeJS Version : v10.16.3
YARN Version    : 1.21.1 

[Nest CLI]
Nest CLI Version : 7.1.2 

[Nest Platform Information]
platform-express version : 7.0.0
common version           : 7.0.0
core version             : 7.0.0

@kamilmysliwiec
Copy link
Member

The root directory for assets is the src folder.

@raydaim
Copy link
Author

raydaim commented Apr 21, 2020

@kamilmysliwiec : putting the files in the src folder does not solve the issue in my original project the assets were in the src and the weren't being copied. I just updated the demo repo with the test.html file in the src folder and it still not being copied

@raydaim
Copy link
Author

raydaim commented Apr 24, 2020

@kamilmysliwiec : any news ?

@EkiGui
Copy link

EkiGui commented Apr 29, 2020

I also noticed an erratic behavior with the copy of assets. After running some tests I figured out that in monorepo mode, it works when I put the assets key in the root compilerOptions but it does not work when I put it in project-specific options.

Just to be clear, in my nest-cli.json:

{
  ... 
  "compilerOptions": {
    ...
    "assets": ["foo/*"] // <----------- Works fine
  },
  "projects": {
    "api": {
      ...
      "compilerOptions": {
        ...
        "assets": ["foo/*"] // <--------- Does not work
      }
    },
    ...
  }
}

I do not know if this is intended but I would say that the docs are not very clear about it.

I am running nest 7.1.2

@EkiGui
Copy link

EkiGui commented Apr 29, 2020

@raydaim When I build your demo repo (nest build) with nest 7.1.2 I get the html file in the dist folder, but it seems that as I described in my previous comment, only the top level compiler option is effective.

This seems counterintuitive to me, given that the assets folder has to be located in the src folder of one specific project.

@raydaim
Copy link
Author

raydaim commented Apr 30, 2020

@EkiGui The issue for me is that even when I put the project specific assets in the root compilerOptions they are not copied to the dist. In my use case, I have some library specific assets ( library-assets ) normally those should be copied to libs\my-library\library-assets which is not the case. I think libraries should be standalone and therefore their assets must not be in the main project.
image

@kamilmysliwiec
Copy link
Member

Can you share your repository ^ from the screen? Unless it's this one attached in the first post

@raydaim
Copy link
Author

raydaim commented Apr 30, 2020

@kamilmysliwiec : it is the same repository, I updated the file structure to highlight the issue

@iamsuneeth
Copy link

I'm facing the same issue when using a library for sharing grpc related code between multiple projects(proto files, clients, etc). As per the code, nest cli copy assets only from the sourceRoot of the project being built. There are no provisions to indicate that the current project depends on assets from outside the srcRoot. I feel there should be an assetDependency option in nest-cli.json to specify the library names those the current project depends on for assets. So when the project being built, cli can copy those assets.

@kamilmysliwiec
Copy link
Member

@raydaim I've pulled your repository again.

First, the assets property should be defined inside the compilerOptions object, so instead of this:

"compilerOptions": {
     "tsConfigPath": "libs/my-library/tsconfig.lib.json"
},
"assets": ["library-assets/*.html"]

it should be:

"compilerOptions": {
     "assets": ["library-assets/*.html"]
     "tsConfigPath": "libs/my-library/tsconfig.lib.json"
},

Next - if you run the npm run start, Nest CLI won't automatically move your library assets as part of the application build because we can't really detect what assets you expect us to move (of which libraries).

For example, if you run nest build my-library, Nest will properly move your assets.

The potential solution for this problem would be introducing another configuration option as @iamsuneeth suggested, but I'm not sure if it makes sense(?) since the directories hierarchy (structure) would be preserved (which in most cases is useless after the bundling process) and this will introduce even more confusion.

TBH, I think that the best way is to group related assets (pulled from different libs) based on the configuration specified by the host application, not libraries because this structure may vary by application.

For now, you can just use this workaround:

"compilerOptions": {
    "webpack": true,
    "assets": [
      "assets/*.html",
      {
        "include": "../libs/my-library/src/library-assets/*.html",
        "outDir": "dist"
      }
    ]
  }

at the application level (root level in this particular case).

@kamilmysliwiec kamilmysliwiec changed the title Assets from libraries not copied to dist even if added to nest-cli.json Make "outDir" for assets more configurable (depth level?) May 13, 2020
@iamsuneeth
Copy link

@kamilmysliwiec Thanks for the workaround. But a strange behavior is being observed after the above changes. Assets are copied to dist directory for all projects except the one configured as root.
yarn start:dev some_project - assets are copied from the library as expected

yarn start:dev or yarn start:dev rootprojectname - assets are not getting copied.

@iamsuneeth
Copy link

iamsuneeth commented May 13, 2020

My bad, sorry. The path of assets is relative to the src root of the project being built. So I had to specify ../../../libs instead of ../libs to correct path.

@DavidHooper
Copy link

This makes it a bit difficult to work with across multiple apps and libraries. Is it possible to workout which apps depend on which libraries/apps and build according to their config too (tsconfig & asset copying)?

Happy to work on this if it applies to the repo. I will need to come up with a solution either way for our large monorepo.

@dg-eparizzi
Copy link

I'd like a way to copy assets in a monorepo workspace without having to put the files inside each project src folder.

I have a single main configuration that's shared between all my apps and I want that file to be available in each app. There doesn't seem to be a way to do this unless I duplicate the same configuration in each project's src folder...

@radulescuandrew
Copy link

@dg-eparizzi The workaround provided by @kamilmysliwiec should work. In the root of the nest-cli.json you specify the relative path to the assets that will be included in the all apps dist folder.

Take into consideration the relative path is starting from sourceRoot to your assets and is not relative to nest-cli.json. See @iamsuneeth answer.

@davidhm117

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants