No publicPath option in configuration file

[manuelcua]

I´ve searched in the source but there´s no way of setting the "publicPath" of my application

It should be inside the webpack output configurations but looking at angualr-cli source it´s not available.

For me it is crucial because I prepend /static/dist/ to load javascript and assets on my app.

I´m using NG version 1.0.0-beta.15

I´m using Django as Server and only doing watch on ng build and Django puts it´s static files in /static/ folder and maps the base URL to a template index.html file so the hrefs in the index files are not relative to the static folder and gets a 404 error.

All of this gets solved if I could add the publicPath configuration in angular-cli.json or environment files

[markus-heer]

This would be great! My build isn't located on the server's base folder, but in the public folder. So after every build, i have to change the strings in my index.html manually again...

[manuelcua]

Also, with this integration we can use the standard way of Lazy Loading modules with the router.

[theDustRoom]

Definitely +1 for this config option; our test and production servers use a subdirectory so having publicPath support is necessary for us but we'd only want it to be used when using the --prod flag during build or serve.

[filipesilva]

You can use the --base-href flag for this: https://github.com/angular/angular-cli#base-tag-handling-in-indexhtml

[manuelcua]

@filipesilva : This does not solve de problem, the --base-href is only to provide root point for the Angular Route Path, not for the root of static files.

[theDustRoom]

@filipesilva I agree with @manuelcua as this is a separate config option for Webpack.

The publicPath specifies the public URL address of the output files when referenced in a browser. For loaders that embed <script> or tags or reference assets like images, publicPath is used as the href or url() to the file when it's different than their location on disk (as specified by path). This can be helpful when you want to host some or all output files on a different domain or on a CDN. The Webpack Dev Server also uses this to determine the path where the output files are expected to be served from. As with path you can use the [hash] substitution for a better caching profile.

[filipesilva]

Ok, seems I misunderstood it's use. I'd be happy to review a PR for this, but bear in mind it should have a test.

[erhard]

found out that js File loading is depending on browser IE Edge output

As you can see from the screenshot IE trys to load from two places, despite only
one is defined in the index.html

<script type="text/javascript" src="ang/inline.js"></script>
<script type="text/javascript" src="ang/styles.bundle.js"></script>
<script type="text/javascript" src="ang/main.bundle.js"></script>

If I add "apollo" to the path than IE seaches in apollo/apollo/ang/.....

While the other browser search at one place. When I write there <script type="text/javascript" src="apollo/ang/main.bundle.js"></script> it take the file from there. While IE would make "apollo/apollo/ang/main.bundle.js"
The workaround is to make the index conditional.

The solution could be a templating where the index template is written by the developper and the %bundle% is replaced by angular-cli.

[naveedahmed1]

Is there any update on this?

[stuartwk]

any update on this?

[filipesilva]

No one has tried to do a PR yet, so no, no update yet.

[mozqt]

I'm not experiencing any issues, but I did find this issue looking for an easy setting to separate the bundled files from distribution root folder, a custom task will do for now, fingers crossed for future.

[changLiuUNSW]

@filipesilva PR created for publicPath support including unit test
#3285

[mwaa]

How soon to have the PR merged? Need publicPath

[rsnj]

I need it as well. We can't store our javascript assets in the root of our server.

[filoxo]

Since changeLiuUNSW's PR is still pending, I found a temporary solution in the webpack docs for outputPath. It suggests that you can add __webpack_public_path__ in your app's entry file, which is main.ts for anyone using the cli. So then my entire main.ts looks something like this:

import './polyfills.ts';

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { enableProdMode } from '@angular/core';
import { environment } from './environments/environment';
import { AppModule } from './app';

declare let __webpack_public_path__: any;
__webpack_public_path__ = "https://cdn.somewhe.re/";

if (environment.production) {
    enableProdMode();
}

platformBrowserDynamic().bootstrapModule(AppModule);

I realize this workaround should (hopefully) only be valid until a PR that enables publicPath is merge.

EDIT: Added variable declaration per below comment.

[piyushchauhan2011]

Hi @filoxo , I tried to do the same as above, but still the script tags and link tags in dist/index.html are not prefixed with the __webpack_public_path__ . Also, noticed that it outputs a warning of somekind while we do ng build --prod. Hence, I decalred the __webpack_public_path__ variable like declare var __webpack_public_path__: any; . Would be good to have your feedback on this.

[filoxo]

Not sure why you'd need the public path in index.html if you could serve that from the same origin as your assets (eg. CDN). My use case is that my backend is Java/Spring, but the js/CSS files are served via a CDN. Therefore the initial `main.js` loads but the additional chunks weren't. Setting the publicPath simply tells webpack's require which origin to request those additional chunks from. And yes, I did notice the `unresolved variable` error during the build; probably should have made note of that in my comment too. I chose to ignore it because it still built successfully, but if declaring it resolved the problem with the TypeScript compiler that'd be good you'd solve the error. Again, though this works the real solution is to build the config into the cli. Hence why I noted that it's a temporary solution until #3285 is merged.

[piyushchauhan2011]

Hmm, my use case is because we are trying to serve the dist/ folder using nginx but with a sub-url , the script, link and assets are not prefixed with that sub-url and fails to load.

I checked the the index.html but it doesn't prepend the sub-url even when we do __webpack_public_path__, don't know why.

@filoxo Is your script and link are prefixed with the cdn path correctly ?

[filoxo]

I don't use the generated index.html because my backend is Java based. Setting the publicPath would only be used after the index file has been served because it's included within the bundle. That said, I don't think that what you're attempting to accomplish would be achieved by setting the publicPath but I'm no expert with webpack so perhaps I'm wrong.

[piyushchauhan2011]

@filoxo Hmm, I've now shifted to parsing out index.html to add necessary changes using python and bs4 https://www.crummy.com/software/BeautifulSoup/bs4/doc/ . Not the prettiest but works for now. Looking forward to the inclusion of publicPath in angular-cli

[filoxo]

@piyushchauhan2011 are you sure you're not just overlooking setting the baseUrl? What you're attempting to do is unrelated to publicPath.

[ghost]

What's the latest on this issue, any PR yet or a work around?

[kuangthien]

Nothing change until now :(
I am using the latest Angular CLI :'(

[filipesilva]

The --deploy-url flag (that does what --public-path does for webpack) has been around for a while: https://github.com/angular/angular-cli/wiki/build

[merwok]

Again, deploy-url doesn’t change static assets paths, which publicPath does.

[hpjc]

I just tested --deploy-url to add public/static as a prefix for the src path and it worked as expected.

command:
ng build --deploy-url public/static

output:

<!doctype html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>Angular2testapp</title>
        <base href="/">
    
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <link rel="icon" type="image/x-icon" href="favicon.ico">
    </head>
    <body>
        <app-root></app-root>
        <script type="text/javascript" src="public/static/inline.bundle.js"></script>
        <script type="text/javascript" src="public/static/polyfills.bundle.js"></script>
        <script type="text/javascript" src="public/static/styles.bundle.js"></script>
        <script type="text/javascript" src="public/static/vendor.bundle.js"></script>
        <script type="text/javascript" src="public/static/main.bundle.js"></script>
    </body>
</html>

[merwok]

These paths are the main app files, not assets like images referenced in other HTML components.
#4517 (comment)

[filipesilva]

We only process images in CSS actually. Images in HTML are not processed. The tracking issue for HTML resource support is #3415.

[feng-xiao]

@filipesilva I'm using cli 1.6.0-rc.0, have set deploy-url to 'assets' in both command line and angular-cli.json. The bundles are prefixed with 'assets' in index.html, but bundle files not copied to the deploy-url folder - assets.

[ltvan]

Yeah, this fixed my problem. We set output path to 'bundles', and deploy-url to 'bundles' as well. The entry point is MVC action from URL /app/ which loaded view from bundles/index.html, so the actual URL (and base href) should be /app/, while the assets are loaded from /bundles/*.

[feng-xiao]

@filipesilva why do I get following error when I'm setting absolute url (http://...) to deploy-url parameter?

--deploy-url and/or --base-href contain unsupported values for ng serve. default serve path of '/' used. use --serve-path to override.

I need to set absolute path to that parameter to support MVC integration.

[filipesilva]

@feng-xiao that sounds like a bug. Can you open a new issue for is to look at?

[feng-xiao]

@filipesilva Hi filipesiva, I entered the issues in #8847

[thescientist13]

@hpjc
Looks like that fix works for me, good call!

[angular-automatic-lock-bot]

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