manifest.json <link hrefs> turn into [object Object]

[jonikorpi]

(Using 0.4.0)

If I add this:
<link rel="manifest" href="./src/manifest.json">

It turns into this in dev:
<link rel="manifest" href="[object Object]">

And into this after build:
<link rel="manifest" href="[object" object]="">

(Found a few issues talking about serving manifest.json but nothing that specifically mentions this happening.)

[gaearon]

This happens because for JSON, we use json-loader (which gives you an object).

We can definitely treat manifest.json specially by convention. To do this, you can send a PR matching that exact name, and using file-loader instead of json-loader. We already have special handling for favicon.ico so you can look at it for inspiration. This entry would need to go before the json-loader in the config for this to work.

We would need to place it outside src directory because it will be impossible to import it from code (you would start getting a file string). I think hardcoding top-level manifest.json to be treated like this is fine.

[gaearon]

cc @andreypopp @mxstbr

[jvorcak]

@gaearon I want to start contributing and I'm looking for a first bug to start with now that I have more time. I could take this one.

[gaearon]

Sounds great, @jvorcak you have it!
I will be away on a vacation but @mxstbr or @eanplatter might be able to review your PR.

[gaearon]

#428 shows a similar approach where we handle a specific filename differently.

[andreypopp]

Would be nice to find a way to configure html-webpack-compiler's loaders separately. That way we don't have confusing special cases added to main config (what if one would want to require the same resource both from index.html template and app code?). Also probably the only loader needed for html-webpack-plugin's compiler is `file-loader, right?

[jvorcak]

@andreypopp I totally agree with that. I've spent some time investigating how that could be done and I got nowhere. There will be other files (apple icons, etc) that will be treated in a same way so I think more general solution needs to be proposed. I'll investigate whether html-webpack-compiler doesn't allow something like this.

[cmmartin]

Why add special rules to the config for everyone's obscure use cases when you can just use the inline loader syntax in your application?

require('file?name=manifest.json!./path/to/manifest.json');

[GillesDebunne]

I have a related problem when trying to fully implement a favicon for my site. I'm following the recommandations from http://realfavicongenerator.net, which aim at providing a nice site icon for browsers, but also when the web site is pinned on a mobile home screen (for PWA).

Using <link rel="icon" href="./src/path/icon.png">, one can easily define a custom favicon for desktop and iOS.

Android however relies on the manifest file referenced in this issue. This file itself needs to reference a relative path to the Android home screen icon. Ideally, webpack should add this icon in the build folder, and its path should be updated in the manifest file.

Finally, IE/Edge relies on a browserconfig.xml file located at the root of the web site, which references the MS tile site's icon, in a way similar to the manifest above.

Check the RFG FAQ for details.

[gaearon]

Why add special rules to the config for everyone's obscure use cases when you can just use the inline loader syntax in your application?

Because we don’t support this syntax officially. Webpack’s inline loader notation has proven to be extremely confusing to many developers, and is incompatible with other bundlers, locking your code into using Webpack.

We may stop supporting it at any moment so please don’t use it.

[gaearon]

Going to move this to 0.5.0 where I want to solve a few issues like this in a single batch.

[gaearon]

I drafted a proposal to solve this in #703. Unless we find some fatal flaws, it should come out in 0.5.0. Let me know what you think!

[gaearon]

Closing as this is fixed, and will be released in 0.5.0.

[gaearon]

This is now supported in 0.5.0.

Read about using the new public folder.

See also migration instructions and breaking changes in 0.5.0.