Parcel: Doesn’t follow <script href>, <script xlink:href>, <a xlink:href> inside inline <svg>

Created on 27 Sep 2019 · 8Comments · Source: parcel-bundler/parcel

🐛 bug report

Scripts should be embedded in <svg> with <script href> or <script xlink:href> rather than <script src>, but Parcel doesn’t find scripts with that syntax.

There are also other tags on which it fails to follow xlink:href, like <a>.

🎛 Configuration (.babelrc, package.json, cli command)

$ tail -n +1 *
==> index.html <==
<!DOCTYPE html>
<svg xmlns:xlink="http://www.w3.org/1999/xlink">
  <script xlink:href="script.js"></script>
</svg>

==> script.js <==
alert(1);
$ parcel build index.html
✨  Built in 327ms.

dist/index.html    101 B    266ms

🤔 Expected Behavior

$ ls dist
index.html  script.d1ea37cd.js  script.d1ea37cd.js.map

😯 Current Behavior

$ ls dist
index.html

💁 Possible Solution

Maybe Parcel should follow all href and xlink:href attributes regardless of tag? But if you want a list of applicable tags, MDN has one for href and xlink:href.

🔦 Context

I wanted to embed TypeScript in a standalone SVG file, which didn’t work because Parcel doesn’t scan standalone SVGs for dependencies at all (#3571), but experimentation with inline SVG revealed this additional bug.

💻 Code Sample

See above.

🌍 Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.12.3
| Node | 12.10.0
| npm/Yarn | 1.17.3
| Operating System | Ubuntu 19.10

Bug

Source

andersk

All 8 comments

Is it canonical behavior for SVG though, to allow embedded scripts?

I mean, nothing technically stops it from working, but SVG isn't exclusively a browser technology and maybe not treating it like any other HTML is actually more anticipated behavior.

The same original argument could be made about XML files as well, but it would be totally weird to treat XML files as HTML files.

kirillrogovoy on 28 Sep 2019

@kirillrogovoy Yes. Did you see the link at the top of my report to the MDN page for the SVG <script> element? It references the relevant specification. It shows that there’s wide browser support. You can try my test case for yourself to see that it works before being processed by Parcel.

I don’t understand why the existence of some SVG user agents that don’t support <script> constitutes an argument that Parcel should break <script> for people who choose to use it on browsers where it does work…

Furthermore, this particular bug is about code inlined into an HTML file, which _is_ a browser technology, even though I don’t see the relevance of that argument.

I would like to see Parcel support for SVG files, but that’s a separate bug. As for XML files—why not? It seems reasonable to treat them as XHTML or SVG if there’s xmlns marking them as such. (It’s XML, there’s no need to blindly guess.) I don’t personally have a use case for XML files, so I’ll leave that as a bug for someone else to file.

andersk on 28 Sep 2019

Fair enough!

I'm curious to see what the maintainers think, but the case for inlined SVG makes total sense to me.

@DeMoorJasper I didn't find that information in CONTRIBUTING.md, so asking here: what's the current policy for fixing bugs in v1/v2. Should I forgo the v1 and go straight to v2, or should I fix both?

kirillrogovoy on 29 Sep 2019

@kirillrogovoy we aren't really releasing any more updates for v1 so probably best to just fix this for v2

DeMoorJasper on 29 Sep 2019

👍1

Fix: https://github.com/parcel-bundler/parcel/pull/3608

kirillrogovoy on 5 Oct 2019

I didn't suggest the support for xlink:href though, because that very doc you linked marks it as deprecated in SVG 2

kirillrogovoy on 5 Oct 2019

SVG 2 is a candidate recommendation; SVG 1.1 is still much more common and only supports xlink:href. Do you really think Parcel should require its users to upgrade to candidate technologies? Is there any harm in leaving that decision to the user?

andersk on 5 Oct 2019

👍1

Fixed by #3608.