/public vs /src/assets behavior

OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)
Mac OSX El Capitan
Versions. Please run ng --version. If there's nothing outputted, please run
in a Terminal: node --version and paste the result here:
angular-cli: 1.0.0-beta.11-webpack.8
node: 5.10.1
os: darwin x64

The latest version of the cli replaces the public directory with the new src/assets directory which works great for copying static files into dist but I'm not sure if the behavior is quite right. Many files are expected to be on the root of a hosted site such as robots.txt and ico files. When the cli copies files over from assets into the dist they are placed at dist\assets. Is there any way to be able to copy files over to the root level of the dist?

This new behavior also affects our projects here. We have had to work around in the obvious hacky way, by building a build process around the CLI-provided build process which adds the files we need at the "root" of the output.

I think most real projects will eventually have at least one, and often many, files that needs to be located somewhere in the "root" of the output - files that CLI doesn't know about and can't be responsible for. Until .webpack.3..8, this was supported and worked very well. I request the feature be put back and kept in the future also.

Summary:

Rename of public to assets: good!
Restriction from being able to locate assets at dist root: bad!

If angular-cli.json can configure "assets" property value as an array, that will be good.

For example:

"assets": ["assets", "robots.txt"],

@doggy8088

I really don't want a solution like @doggy8088 outlined, in which I need to... tell... CLI... about... each... and... every... file... I... want... to... include.....

@christiandreher

@christiandreher Actually, I like the original pubilc folder design better than current one. For the current 1.0.0-beta.11-webpack.8 design, the src/assets will copy to under dist/ so there is nothing can copy to the root of the 'dist/' folder, only the assets folder does.

/public was fine, in my opinion (while also adding the possibility to customize copying other files too, like they've added /src/assets). But the /public folder behavior needs to be brought back (under the same or under a different folder name or even better: give us to possibility to set it up or not, our choosing). Problem with /public was: the cli was not copying .dot files over (like .htaccess) - see #1758. And when they fixed copying .dot files, they've also removed the /public folder, and closed the ".htaccess not getting copied" bug :)) nice :|
We definitely need to have files copied to the root of the /dist folder, and certainly not to have to point the cli to each and every single file.
Anyway, adding the /src/assets folder is not bad, perhaps. Although we could have been able to create an assets folder (or many other folders) in /public and everything from /public should have been copied over as is, keeping the folder structure - I think this would have been the ideal behavior.

This is preventing our team from upgrading to the latest CLI version as we have to have files in the root during development time. ng serve and ng build --watch wipe out the dist directory when building at development time. Has anyone come up with a workaround for this?

It shouldn't have anything to do with the "mode" we're in (development or production). Custom files need to be copied to dist root no matter if you're in development mode or building for production

@MrCroft

@MrCroft correct, we have a workaround for a ng build command, just have a script to copy the files over to the dist but as for dev time ng serve or ng build --watch there doesnt seem to be a temporary workaround for this. I'm looking around to see if I can submit a PR but unfortunately my webpack skills are not up to par so might take a bit to figure how everything works.

@filipesilva

@filipesilva also referenced this: #2232

I was hosting bower references (polymer) into the public/bower_components
and referencing it from index.html with something like this


  <!--Polymer-->
  <script src="bower_components/webcomponentsjs/webcomponents.js"></script>

  <script>
    window.Polymer = window.Polymer || {};
    window.Polymer.dom = 'shadow';
  </script>

  <!--Polymer-->
  <link rel="import" href="bower_components/polymer/polymer.html">
  <link rel="import" href="bower_components/paper-styles/color.html">

So i tried to redirect the reference to assets/bower_components. it didn't
work, 404s. I'm thinking there is more to it than a directory rename and
would appreciate it if someone could confirm that. Perhaps, webpack has a
subtle change from it's former public behavior.

Can anybody confirm, that the move to assets is more than just a rename of
the folder?

@robertbaker

@robertbaker - you got me encouraged for a moment, but the NPM polymer is not the polymer I'm referring to. The one I'm referring https://www.polymer-project.org/1.0/ which happens to be a google project. The docs all say it's bower. It's much farther along, today than Angular2 Material Design. At this point, I'm looking any solution, I'm thinking about serving these dependencies CDN style, at least until I can figure a way to include them in my build.

I'd generally expect support in angular-cli for polymer. They both come out of the googleverse after all.

@filipesilva

@filipesilva would it be too bold to ask what are the major downsides of the following approach?

Bring back public folder into the root, same level as src
Add a key copyToOutput, pointing at "public"
Copy the folder to output with some Webpack copy plugin

I can think of a few questions you might ask

It might complex / confusing people
You can avoid generating folder and key by default, and leave it as documented feature only
People might be greedy and ask for an array
Shouldn't be a big difference though to implement or ignore
What if people want it in src, or even apps
Since it's relative to root, people can still do that

Are there other concerns with this approach compared to other approaches? It's the closest one to the old approach, which is proven valuable by many comments here.

P.S.

Thanks a lot for all your own voluntary efforts in this free tool

Another workaround for those who need to include web.config into the prod build, here is another workaround that works. I simply added an entry for it in the assets section of angular-cli.json
"assets": [
"assets",
"favicon.ico",
"Web.config"
]
Webpack will then copy it from src/app to the root of dist.

Oh, cool. Sorry, Looks like I got the wrong idea looking through the thread that we are looking for a solution equivalent to the /public folder.

Is there really no other way than typing every file into apps[0].assets?

Eg. when using http://realfavicongenerator.net to generate the favicon files you get ~10 files - thats a lot of clutter to have in the root folder. (Not including .htaccess or web.config and robots.txt)

@robertbaker

@robertbaker Sure, but the recommended way is to put the files in the root folder.

http://realfavicongenerator.net/faq

Why do you recommend to put all files at the root of the web site?
When generating a favicon with RealFaviconGenerator, the instructions ask you to place all files at the root of your web site. You may want to place them in a sub-directory, for example in http://mywebsite.com/icons/, just to make things clearer. However, there are three drawbacks with this approach:

Internet Explorer looks for favicon.ico at the root of the web site. Granted: this is because we ask you to not declare favicon.ico.

iOS devices look for files such as apple-touch-icon-144x144.png at the root of the web site, as described by Apple. This issue can be mitigated by declaring the icons in the HTML code (this is necessary for Android anyway), but following Apple conventions is probably the best move.

By default, Internet Explorer 11 looks for browserconfig.xml at the root of the web site.
Several services, such as Yandex, look for favicon.ico in the root directory.

Why is favicon.ico not declared in the HTML code?
Looking for some sample favicon code, you've probably encountered:
<link rel="shortcut icon" type="image/x-icon" href="favicon.ico">
When your favicon is in the root directory, RealFaviconGenerator does not generate this code. This is because it somehow confuses some other browsers like Chrome. And since IE looks for a file named favicon.ico anyway, the best solution is to not even talk about it. This is described by Jonathan T. Neal (http://www.jonathantneal.com/blog/understand-the-favicon/) and Mathias Bynens (http://mathiasbynens.be/notes/rel-shortcut-icon).

Really? But W3C says this is a bad thing!
Yes, W3C discourages the usage of a predefined URI. If you follow this recommandation, you will get into troubles with browsers which wrongly choose favicon.ico instead of the nice PNG versions gently prepared just for them. It is way better and pragmatic to trick them with this little hack.

this almost works

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.}

Navigation Menu

Repository navigation

/public vs /src/assets behavior #1942

36 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

/public vs /src/assets behavior #1942

Description

Activity

kylecordes commented on Sep 2, 2016

kylecordes commented on Sep 2, 2016

doggy8088 commented on Sep 2, 2016

kylecordes commented on Sep 2, 2016

doggy8088 commented on Sep 2, 2016

NgxDev commented on Sep 3, 2016

coryrylan commented on Sep 5, 2016

NgxDev commented on Sep 5, 2016

coryrylan commented on Sep 5, 2016

36 remaining items

peterennis commented on Sep 22, 2016

jjarrell50 commented on Sep 22, 2016

jjarrell50 commented on Sep 22, 2016

Meligy commented on Sep 22, 2016

cheresier commented on Nov 19, 2016

cheresier commented on Nov 19, 2016

Nikkelmann commented on Mar 2, 2017

Nikkelmann commented on Mar 7, 2017

angular-automatic-lock-bot commented on Sep 6, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions