Parcel: 🐛 Problem with loading manifest.json

[mvrlin]

🐛 Bug report

While building or running in dev mode with parcel, if I include manifest.json in html, then parcel return's me .js file path.

🤔 Expected Behavior

<link rel="manifest" href="/dist/manifest.json">

😯 Current Behavior

<link rel="manifest" href="/dist/05bfa35095e6bfacdb8b334d1023872b.js">

🌍 Your Environment

| Software | Version(s)
| ---------------- | ----------
| Parcel | 1.2.0
| Node | node 8.9.2
| npm/Yarn | yarn 1.3.2
| Operating System | macOS Sierra 10.12.6

[davidnagli]

Thanks for reporting this 😀

It looks like you have a mistake in your code. Instead of using the path to the manifest.json in dist, you should be setting the path to your original manifest.json, and Parcel will handle transforming it to the correct path within dist.

You should be doing something like:

<!-- Assuming your manifest.json file is in a directory called src -->
<link rel=“manifest” href="/src/manifest.json">

[kylealwyn]

Can confirm this behavior. Any JSON file referenced in html entry is transformed to js module

[mvrlin]

@davidnagli I tried your solution, it's converting json to js and as .js path return it.

[DeMoorJasper]

This is expected bahaviour looking at the code but in reality shouldn't happen, marked this as bug

[zhulduz]

Is it correct that a file JSONAsset.js extends JSAsset.js?

Maybe JSONAsset should look likes this (of course with some improvements).

[HenrikJoreteg]

I'm happy to take this on, as it is a bit of a blocker for me for migrating a couple of PWAs to parcel.

My questions:

• Would it make more sense to just consider manifests something that should be ignored? (it'd be easy to add an exclusion for <link/> tags with a rel='manifest'.
• If not, is there a way to add an option here: https://github.com/parcel-bundler/parcel/blob/master/src/assets/HTMLAsset.js#L49 that specifies that it should be kept "raw" in that circumstance?

@devongovett any guidance?

[devongovett]

Ah interesting issue. The type needs to be js so JSON files can be imported from JavaScript. Ideally the assets could return multiple renditions of different types and the correct one could be chosen based on the parent asset type. Let me think about this a bit and see what I can come up with. If you have suggestions on how this could work let me know!

[HenrikJoreteg]

@devongovett it's weird, because how to handle this file can't be inferred from its file type. This isn't a JSON file that needs to be read and used as a module, it's just a JSON file that needs to be copied into the build directory. I started in on this by adding a check to determine if the link tag has a ‘rel=manifest‘. It'd be cool if addURLDependency took an option to specify that it should be "raw".

[albizures]

Hi @devongovett, I faced something similar working with the implementation of rust/wasm.
My case was that I needed to make some difference between the wasm files that were called from html file or the js files.

So I came up with this:

-let assetPath = this.addURLDependency(node.attrs[attr]);
+let assetPath = this.addURLDependency(node.attrs[attr], {
+  fromHtml: true
+ });

I'm not sure if this is the best way to do it, but it works 😄
you can see the changes in my PR #312

but I think your idea using the parent's type is a better way to do it.

[DeMoorJasper]

@albinotonnina wouldn't it be a better idea to make from a more generic field like

let assetPath = this.addURLDependency(node.attrs[attr], {
  from: asset.type
});

resolving into

let assetPath = this.addURLDependency(node.attrs[attr], {
  from: 'html'
});

I'm not sure but thought there was a way to address the parent element already, i might be mistaken

[albizures]

yes, I agree with you @DeMoorJasper and I looked for a way to address the parent, but I didn't find a way, but maybe I just didn't look in the right place 🤔

[Munter]

With all the years of experience I've had thinking about these graph problems while implementing Assetgraph, I can tell you that you won't be able to infer from the asset alone what format you need to keep it in. Knowing the parent type will only be enough in the most naive cases as well. What you need is a model that also keep the information of what type of relation is between these two assets.

In Assegraph each way any asset can refer to a different asset is modelled as different relation type. This information has turned out to be much more valuable than the assets themselves, as you can infer a lot of things from the relation types alone. It's especially valuable when you start to traverse the graph for processing.

In this single case you might be able to hack it with a condition that excludes json files linked from html from being interpreted as js. But a bit further in the future you might want to cover the case where fetch('data.json') is picked up as a file reference, and the application logic of runtime json loading would fail if the file changes extension as well.

You probably also want to start treating the webmanifest as a separate asset type inheriting from JSON, since it has well defined properties that also describe asset relations.

[niicojs]

I was also blocked by this so I made a PR that works for me: #690

[vlucas]

Just got here after some searching because I hit this very issue myself while trying to create a PWA with a manifest.json file.

I think that in general, the most flexible thing from an HTML entry point would be to have some data attribute that we could use to manually tell Parcel.js NOT to process the file.

Something like this:

<link rel=“manifest” href="/src/manifest.json" data-parceljs-ignore>

That data attribute would then be noted, processing would be skipped for that file, and the resulting output would remove the data attribute without doing any processing on the file at all:

<link rel=“manifest” href="/src/manifest.json">

[niicojs]

Parcel will have to process the file as it may contain links to assets (images mostly).
Did you try <link rel='manifest' href='/src/manifest.webmanifest'>. This is supposed to work.

[vlucas]

Yes, I tried that - I was able to get everything working, but I still wish there was a way to tell ParcelJS to ignore files individually. Thanks!

[aminnairi]

I was using the manifest.json naming convention from the Google Web App Manifest documentation. While MDN was using the manifest.webmanifest naming convention. Using the later solved the issue (which was Parcel.js converting the manifest.json to a javascript file). Hope this helps!

[vlucas]

@aminnairi Yep, that's what I did too. Mine is now named manifest.webmanifest and it works.

[aviaryan]

webmanifest solution might work but I want to name my manifest as manifest.json. Any way to achieve that?

[antoniovj1]

Any news on this?

[manthis]

I have just renamed my manifest.json file to manifest as a temporary workaround.

[HenrikJoreteg]

@devongovett @DeMoorJasper hey! Just wanted to drop a quick note here for parcel v2. In talking to some friends at Google, it's important for how browsers handle web manifests specifically that the final filename stays the same between builds.

Otherwise it's interpreted as a different app, somehow. Maybe @slightlyoff or @addyosmani can elaborate a bit.

In order to work around this I've had to do some HTML manipulation after the fact to inject the manifest.

I just wanted to drop note in hopes that there would be some way to control the final filename in v2.

Thanks for all your work on Parcel! ❤️

[devongovett]

@HenrikJoreteg hey, catching up here. Was your manifest being output with a hash or something? It shouldn't because the dependency in HTML is marked as an entry, which means it should be consistent. So that should already be the case. Let me know if there's something else you're looking for.

[neuroelf]

Hey there. My use case is probably different: I've used create-react-app and now want to have a relatively easy (few mangling steps) way of bundling all assets with parcel--which BTW works awesome, not requiring to eject!

And I simply wanted to say it'd be great if there was a way to bundle/build with a tag/token of sorts that copies the original manifest.json file into the build folder (with that filename) and keeps the original content (link tag with rel="manifest" and href="/manifest.json" fields), even if in the original index.html file another tag (e.g. parcel-asset-copy-only) needed to be added, which I could do pre-build...

As a first pass, it's not too many steps:
https://github.com/neuroelf/dermodelphi/blob/master/README.md#building-with-parcel-without-minification

Anyway, great project!! :)

[benhormann]

How about putting manifest.json as an entry point? Then we know it shouldn't be renamed or converted to a module.

This is what I had in mind:
parcel src/manifest.json src/*.html src/*.js --hmr-hostname localhost

Parcel currently converts the manifest to a module even though it isn't referenced in any code.

_* I later found the plugin for browser addons._

[GeoffMahugu]

I was using the manifest.json naming convention from the Google Web App Manifest documentation. While MDN was using the manifest.webmanifest naming convention. Using the later solved the issue (which was Parcel.js converting the manifest.json to a javascript file). Hope this helps!

This worked for me,