Maybe as a separate package?
Or within the html-css-minifier package, but it means that "html-css-transformer" will be a better name.
It's a nitpick, and both can coexists for a moment…
The idea is to expose to the user a chance to alter collected CSS/HTML literals, before and after minification (or minification could be a plugin alongside the other transformers).
API could look like the Shiki one.
I will post further details on this issue, but the use cases are very wide:
- Strip typescript typings in inline
<script> tags
- Collect and strip
<script type="module">
- Collect and strip user-defined metadata on tags (they could just do whatever they want within hooks, put up parse5,
hast, etc)
- Preprocess HTML/CSS/JS in case of the minifier is choking on a newer syntax, which happened quite often (from my experience,
& nested selector took a while to be supported by minifier). Most of the time, PostCSS etc is taking care of that, but not always for inline tags, which is why we use @literals/ toolset, for things like hard to reach, composite source code.
Most above use-cases are quite SSR centric, admittedly, but in the end, that will benefit for both sides, client and server.
About the TypeScript thing, that could be a plugin on its own, Prettier actually support <script lang="ts|typescript"> perfectly for formatting html literals.
The last one ingredient is IDE awareness for this feature stack to shine, which could theoretically be leveraged by a typescript plugin that use this package too (if we make the minification a separate transformer, so VSCode and Monaco could use this is their TS LSPs without unwanted deps. but that is off-topic).
Interestingly, html-minifier-terser is already providing a preprocessScripts, but it's not very flexible and useful for more ambitious endeavours.
Maybe as a separate package?
Or within the html-css-minifier package, but it means that "html-css-transformer" will be a better name.
It's a nitpick, and both can coexists for a moment…
The idea is to expose to the user a chance to alter collected CSS/HTML literals, before and after minification (or minification could be a plugin alongside the other transformers).
API could look like the Shiki one.
I will post further details on this issue, but the use cases are very wide:
<script>tags<script type="module">hast, etc)&nested selector took a while to be supported by minifier). Most of the time, PostCSS etc is taking care of that, but not always for inline tags, which is why we use@literals/toolset, for things like hard to reach, composite source code.Most above use-cases are quite SSR centric, admittedly, but in the end, that will benefit for both sides, client and server.
About the TypeScript thing, that could be a plugin on its own, Prettier actually support
<script lang="ts|typescript">perfectly for formattinghtmlliterals.The last one ingredient is IDE awareness for this feature stack to shine, which could theoretically be leveraged by a typescript plugin that use this package too (if we make the minification a separate transformer, so VSCode and Monaco could use this is their TS LSPs without unwanted deps. but that is off-topic).
Interestingly,
html-minifier-terseris already providing apreprocessScripts, but it's not very flexible and useful for more ambitious endeavours.