Parcel v2 and absolute og:image

[hsablonniere]

Hello 😄

Context

I'm using Parcel (v2) as an optimization step once my static site is generated. Therefore, I give Parcel a static site that already "works", with files that I could host as is. It's just that all those files are unminified, unbundled, images are unoptimized etc... I expect Parcel to take this static site and output a better version. One with optimized assets and where filenames are hashed for better cache.

Because the HTML source files I give to Parcel are 100% valid, my og:image URLs are already defined as full URLs with the target host, ex: https://example.com/my-article/og-img.jpg. This is expected by sites like Twitter. Relative URLs don't work.

The problem

The HTML transformer looks for those kind of og:image URLs and it's one of the things I like about Parcel. These kind of details, especially for HTML, are handled. The problem is, because my og:image input URLs are "full" with the target host, Parcel can't "link" them to assets in the bundle graph and therefore can't rewrite them with the hashed filename of the optimized image.

Investigations

I tried and confirmed that giving Parcel HTML files with relative URLs for og:image works as an input. It recognizes the assets in the bundle graph and rewrites filenames with hashes properly.

I don't want to do this. An HTML file with relative URLs for og:image doesn't work once it's hosted online. I don't want to give Parcel a static site that doesn't work as is and I don't want Parcel to give me a static site that doesn't work as is. Technically, it outputs absolute URLs but without any target host so they're still "broken".

I had a look at the different HTML plugins (transformer, packager...). I also had a look at how dependencies and how URL replacements work.

Solution 1

I created a custom transformer for HTML files. I used it before the official HTML transformer in my config. This plugin knows about my target host and looks for og:image with full URLs. It computes a relative URL from the full URL, then calls asset.addURLDependency(relativeUrl) and replace the HTML node with the dependency id.

This breaks because then the official HTML transformer sees a dependency id in the content attribute of the meta tag and cannot resolve it:

parcel/core: Failed to resolve '0cec9a37ea75be8dab4e5645803d9b51' from './_site/index.html'

I patched the HTML Transformer so it would ignore og:image meta tags and then the whole thing worked. When I say worked, I mean, I managed to make Parcel understand my full URLs with target host as un input, the ouput contained the filename with th hash but it was still an absolute URL without the target host.

Then I had the idea in my plugin to set the content attribute to targetHost + id instead of just the idea. This worked. I finally had full URL as input and full URL (with hash) as output.

Last problem was that I had to patch official HTML transformer.

Solution 2

I created another plugin but this time I place it after the official HTML transformer. Here's what it does:

• Look for og:image meta tags
• Look at the id that was set in the content attribute
• Look at the HTML file dependencies and find the original full URL
• Resolve the relative URL from the full URL with target host
• Create a new dependency with the relative URL
• Replace the meta tag content attribute already containing an id with targetHost + relativeId where relativeId is the one from the dependency corresponding to the relative URL.

THIS WORKS!! 🎉 This feels very hacky but I didn't have to patch the HTML transformer for this.

Proposition

Even if solution 2 works for me right now. I would like to discuss with the team how we can solve this in a better way.

• It would awesome if I could say "hey HTML transformer, this full URL with target host is this local file". I wouldn't need any custom plugin. I clearly don't see how this could be done properly.
• It would be nice if I could say "hey HTML transformer, I already created dependencies for these tags, ignore them".
• Maybe just a plugin to transform those full URLs into relative URLs, then let Parcel do its magic but have a publicUrl that is only used in the HTML packager for thos og:image URLs that must be full with a target host.

Thanks

This was very long, sorry. I'm not sure if I make sense, let me know if I can clarify something. I know my context may be different from many Parcel users working with SPAs but I really think using Parcel to optimize a static site this way is a great goal.

[101arrowz]

Have you taken a look at the public URL option? It allows you to force an absolute path. See the docs for target options.

Also, if you don't want to have to rewrite the URLs from your existing site, make the site in your project root so that the paths are resolved as if they were relative. See the module resolution docs.

[hsablonniere]

Hello @101arrowz ;-)
Thanks for taking the time to answer me.

Right now, I'm using Parcel with an npm script that calls this:

parcel build '_site/**/*.html' '_site/*-feed.xml' _site/robots.txt

This way, Parcel takes all my HTML articles built by my static site generator.

I saw the publicUrl option but I don't see how I can use it in my context.
I don't have a JavaScript library to build, I have several HTML files that I canno't list explicitly in my package.json.

I also saw the --public-url CLI param.
This option works to add the public URL in the output but it does not seem to be used to recognize absolute URLs as un input. Am I right?

The other problem that I tried to describe in my previous message is, I don't want absolute URLs everywhere, just where it's mandatory (like OG images or RSS feeds).

[101arrowz]

Absolute paths in the input files can only really be resolved by having the files in the root directory of the project, i.e. in the same directory package.json. So if your package.json is at path/to/package.json, _site/hello.html must become path/to/hello.html, _site/articles/a.html must become path/to/articles/a.html, etc.

It's not particularly simple to have the public URL be prepended to links in certain tags but not others with the default config; I think the plugins you made were necessary for that.

By the way, do you have a central HTML file that links to all the others? Rather, can you go from some particular HTML file to any other page in your site? If you bundle just that with Parcel, it will automatically pick up the others, and you don't need to glob every HTML file.

[hsablonniere]

Absolute paths in the input files can only really be resolved by having the files in the root directory of the project, i.e. in the same directory package.json. So if your package.json is at path/to/package.json, _site/hello.html must become path/to/hello.html, _site/articles/a.html must become path/to/articles/a.html, etc.

I'm not sur I understand what it means. I'll have another look at the module resolution docs.

It's not particularly simple to have the public URL be prepended to links in certain tags but not others with the default config; I think the plugins you made were necessary for that.

Yeah I totally get that (even if I kinda consider those tags to be special as they will never work if they don't contain the origin).
I would conclude the same if I were a maintainer.

By the way, do you have a central HTML file that links to all the others? Rather, can you go from some particular HTML file to any other page in your site? If you bundle just that with Parcel, it will automatically pick up the others, and you don't need to glob every HTML file.

Not really, it's just a site/blog with articles.
Right now, my 2 articles are listed on the home page but as any blog, it won't always be the case.

[hsablonniere]

Reduced tests I did:

Input relative URL

Input:

<!-- test-parcel/index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta property="og:image" content="opengraph.jpg">
</head>
</html>

Command:

build test-parcel/index.html

Ouput:

<!DOCTYPE html><html lang="en"><head><meta property="og:image" content="/opengraph.7bb51fde.jpg"></head></html>

👍 That's kind of the result I would expect:

• The Open Graph image is identified as dependency.
• The file is hashed and renamed.
• The URL in the HTML output is replaced with the hashed name.

🤔 Drawbacks:

As I explained in my first comment, having Parcel handling those special meta tags is awesome but they will be useless if URLs are not absolute.

Input relative URL with --public-url

Same HTML input.

Command:

build test-parcel/index.html --public-url https://www.hsablonniere.com

Ouput:

<!DOCTYPE html><html lang="en"><head><meta property="og:image" content="https://www.hsablonniere.com/opengraph.7bb51fde.jpg"></head></html>

👍 That's an interesting result:

• The Open Graph image is identified as dependency.
• The file is hashed and renamed.
• The URL in the HTML output is replaced with the hashed name.
• The URL is prefixed with the origin I set with --public-url.

🤔 Drawbacks:

• I still have an absolute origin less URL as an input.
• Now all my URLs will be prefixed with the --public-url.

Input absolute URL with --public-url

Input:

<!-- test-parcel/index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta property="og:image" content="https://www.hsablonniere.com/opengraph.jpg">
</head>
</html>

Command:

build test-parcel/index.html --public-url https://www.hsablonniere.com

Ouput:

<!DOCTYPE html><html lang="en"><head><meta property="og:image" content="https://www.hsablonniere.com/opengraph.jpg"></head></html>

Broken result per my expectations.

🤔 Drawbacks:

• The Open Graph image is NOT identified as dependency.
• The file is NOT hashed, NOT renamed and NOT copied in dist.
• The URL in the HTML output is NOT replaced with the hashed name.

As I explained in my first comment, I want to use Parcel as an optimization step on the output of my static site generator.
I think it has great potential to be used this way.
That means I want to give it a working website, with absolute Open Graph URLs with the public origin.

[101arrowz]

I had misunderstood what you meant by "inputting absolute URLs". Indeed, Parcel will have a hard time transforming https:// URLs. Custom plugins are definitely necessary in this case.

[hsablonniere]

Yeah sorry, I should have been more precise saying with the explicit target origin.

[hsablonniere]

Looking again at my "propositions" (numbered this time):

It would awesome if I could say "hey HTML transformer, this full URL with target host is this local file". I wouldn't need any custom plugin. I clearly don't see how this could be done properly.

As expected, this is not really something that can be done easily as some kind of option in core.

It would be nice if I could say "hey HTML transformer, I already created dependencies for these tags, ignore them".

Being able to place a plugin before @parcel/transformer-html would be nice.
I would need a way to tell @parcel/transformer-html to ignore some tags that I already recognized and handled as dependencies.

Maybe just a plugin to transform those full URLs into relative URLs, then let Parcel do its magic but have a publicUrl that is only used in the HTML packager for thos og:image URLs that must be full with a target host.

I'm not sure if it's possible now, but if I could create a dependency with a custom publicUrl only for this one, it would be awesome!