Add html-loader functionality

[m10]

It would be really awesome if you could add functionality similar to that of html-loader.

html-loader parses the html and automatically adds assets as dependencies. Something similar should be possible for pug.

TMK this happens on the basis of a list of tags and attributes that should be treated as assets.

Adding this functionality would eliminate the need to use require for assets making the DX even more awesome.
(parcel also does this. HTML as entypoint with automatic asset loading)

Using require for assets could ideally still be optionally possible.

[webdiscus]

@m10

Thank for good idea :-)
We can discuss it.

1. When we need to define a static assets (vendor scripts, vendor css, vendor images, etc) these already are in public directory, then we can write this public path without require():

link(href="/static/vendor/css/styles.css" rel="stylesheet" )
script(src="/static/vendor/lib/socket.io.js")
img(src="/static/vendor/images/logo.png")

2. If we want use in Pug the source files, then we can use the require():

link(href=require('~Styles/main.scss') rel="stylesheet" )
script(src=require('~Scripts/main.ts'))
img(src=require('~Images/logo.png'))

How can we differentiate the path when we should leave it as it is and when we should compile the sources?
I known, html-loader has a filter option, where we can write a function and self decide, but is very bad practice. Easily is use the require() for source files and not use it for static assets.

I see only one case for " leave it as is", it is URL like:

img(src="https://vendor/images/logo.png")
img(src="http://vendor/images/logo.png")
img(src="//vendor/images/logo.png")

But what should be with others?

[m10]

Mmh I understand the problem.

The filter option still seems the best way to keep the source as "native" as possible. I understand that it is not good practice but I am still favorable to provide the possibility and let the user decide whether to use it.

I believe that even URLs are not safe to be left as is with webpack's experimental buildHttp feature.

One probably could add a "static-asset-loader" (or similar) that just returns the path/URL as is. It woul be possible to use e.g. "!!static-asset!/some/path-or-url" as path. One could then also add loader rules to the webpack config (e.g. also using issuer option) to imlpement a kind of "filter" so the plugin would not strictly need to support this option directly.
The loader inline syntax does not look super elegant though and is not really intuitive. Also it would "just" turn things around: Instead of amending non-static assets with require we would have to amend static assets with the loader prefix. The use case of having static assets IMO seems much less common though.

Right now I can't think of any other way to handle this but having the mentioned possibilities and making the auto-loading feature optional would be enough IMO.

[webdiscus]

Specification for new syntax

I think that the usage a prefix for static assets would be good candidate for solution.
As additional way, we can add the filter: (request) => {} option like in html-loader, for true hardcore developers ;-).

We can define the prefix for static assets like asset-static (by analog with name of loader type: asset/resource).
Then we can use Webpack syntax for inline loaders: !!asset-static!/path/to/static/style.css

Note: the !! to a request will disable all loaders specified in the configuration.

Usage of static assets with pug-loader

//- local hosted static assets
link(href="!!asset-static!/vendor/css/styles.css" rel="stylesheet" )
script(src="!!asset-static!/vendor/lib/socket.io.js")
img(src="!!asset-static!/vendor/images/logo.png")

//- URL to remote static assets, note: the `//` is equal to both `http://` and `https://`,
    here is the prefix `!!asset-static!` optional
script(src="!!asset-static!//vendor/lib/socket.io.js")
script(src="//vendor/lib/socket.io.js")

Usage of source assets with pug-loader (defaults, w/o any prefix)

link(href='~Styles/main.scss' rel="stylesheet" )
script(src='~Scripts/main.ts')
img(src='~Images/logo.png')
h1 Hello Pug!

PRO:

• In 99.8% of cases we use source files of assets, so we save writing require(...)

CONTRA:

• fatal BREAKING CHANGE, many thousands developers who already use current syntax will be angry
• the usage of require(...) for embedded assets is overall documented for millions auditory since many years
• the "new" syntax in Pug, like html-loader, is not intuitive and can be confusing

For transition period to new syntax, by using the require(...), will be shown a deprecation warning.

---

In general, I support your Idea to avoid usage require() for asset source per default.

But this idea should be accepted by the pug community.
I would like to discuss this with many developers.
Do you can help to promote this discuss for "Specification for new syntax"?

[webdiscus]

It would be really awesome if you could add functionality similar to that of html-loader.

html-loader parses the html and automatically adds assets as dependencies. Something similar should be possible for pug.

TMK this happens on the basis of a list of tags and attributes that should be treated as assets.

Adding this functionality would eliminate the need to use require for assets making the DX even more awesome. (parcel also does this. HTML as entypoint with automatic asset loading)

Using require for assets could ideally still be optionally possible.

one year later ...

Hello @m10,

I didn't forget about your suggestion.
I'm currently working on the next mega cool plugin html-bundler-webpack-plugin.
This is new best alternative to outdated html-webpack-plugin.

This plugin works like the pug-plugin (on same code base), but you can use any HTML templating engine such as Eta, EJS, Handlebars, Nunjucks, LiquidJS and others without template loaders.

This plugin have same as by pug-plugin:

• An HTML template is an entry point
• Source scripts and styles can be specified directly in HTML using <script> and <link> tags
• Inline JS, CSS, SVG, PNG without additional plugins and loaders

What is NEW:

• (Exact what you want) Resolving source assets specified in default attributes href src srcset etc.
  The same as by html-loader
• Using any template engine via the preprocessor option
• Support for both async and sync preprocessor
• Pass own a data object into a template
• Default loader support EJS-like syntax. No template loader is required. For support other engine, simple define it in preprocessor

You can see usage examples in README.

I will add the auto resolving of standard attributes in pug-plugin, in the next pug-plugin v5.
The old require() syntax will remain for compatibility:

img(src=require("./logo.png"))
img(src=require("../images/logo.png"))
img(src=require("@image_alias/logo.png"))

New syntax to resolve source files:

img(src="./logo.png")
img(src="../images/logo.png")
img(src="@image_alias/logo.png")

But, w/o require() is impossible the interpolation of a file path:

- file = 'logo.png';
img(src=require(`../images/${file}`))

Than do you think about?