Multiple <template> tags causes a ParseError #310
Description
Describe the bug
Multiple <template> tags causes a ParseError.
Logs
(included under stacktrace section)
To Reproduce
As per the Getting Started guide:
npx degit sveltejs/template my-svelte-app
cd my-svelte-app
npm install -D svelte-preprocess
npm installNo language-specific dependencies were added, only the main library.
sveltePreprocess was added to the rollup config.
Replace the contents of App.svelte:
<template>
<h2>Hello!</h2>
</template>
<template>
<h2>something has gone terribly wrong</h2>
</template>Expected behavior
- I expected
<template>tags to not render as they wouldn't in normal HTML or even Svelte.
Prior to digging deeper into my setup I was not aware this was a default feature ofsvelte-preprocess. - As per the above, I expected multiple
<template>tags to work as in normal Svelte (see REPL).
Stacktraces
Stack trace
bundles src/main.js → public\build\bundle.js...
[!] (plugin svelte) ParseError: </template> attempted to close an element that was not open
src\App.svelte
1:
2: <h2>Hello!</h2>
3: </template>
^
4: <template>
5: <h2>something has gone terribly wrong</h2>
ParseError: </template> attempted to close an element that was not open
at error (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\svelte\src\compiler\utils\error.ts:25:16)
at Parser$1.error (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\svelte\src\compiler\parse\index.ts:100:3)
at tag (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\svelte\src\compiler\parse\state\tag.ts:140:12)
at new Parser$1 (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\svelte\src\compiler\parse\index.ts:52:12)
at parse (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\svelte\src\compiler\parse\index.ts:216:17)
at compile (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\svelte\src\compiler\compile\index.ts:90:14)
at Object.transform (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\rollup-plugin-svelte\index.js:111:21)
at ModuleLoader.addModuleSource (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\rollup\dist\shared\rollup.js:18542:30)
at ModuleLoader.fetchModule (C:\Users\GrygrFlzr\Documents\projects\template-tags-preprocess\node_modules\rollup\dist\shared\rollup.js:18598:9)
at async Promise.all (index 0)
Information about your project:
System:
OS: Windows 10 10.0.19042
CPU: (16) x64 AMD Ryzen 7 3700X 8-Core Processor
Memory: 12.36 GB / 31.95 GB
Binaries:
Node: 14.15.3 - C:\Program Files\nodejs\node.EXE
npm: 7.5.2 - C:\Program Files\nodejs\npm.CMD
Browsers:
Chrome: 88.0.4324.150
Edge: Spartan (44.19041.423.0), Chromium (88.0.705.63)
Internet Explorer: 11.0.19041.1
npmPackages:
rollup: ^2.3.4 => 2.38.5
svelte: ^3.0.0 => 3.32.2
svelte-preprocess: ^4.6.6 => 4.6.6
Additional context
I first encountered this issue at FredKSchott/snowpack/discussions/2595 (using snowpack with svelte) at which point I was directed here. I am unsure what should be done about this.
In isolation, this is clearly due to the template feature reusing the HTML <template> tag as its default markup option, and greedily consuming everything between the first opening tag and the last closing tag as markup to render.
In practice, unless Svelte itself handles <template> as a special case (like it already does with <slot>), it is surprising behavior to not to be able to use a HTML tag normally without going out of your way to configure the preprocessor from the default markup tag. Both the Snowpack 3 guide for using Svelte and the upcoming Svelte-Kit make use of this preprocessor, so there will be a number of indirect users who are not aware of svelte-preprocess's <template> feature.
It is to my current understanding that this is a longtime default of the preprocessor (going back several years now?) so that changing the default is likely infeasible. Would it be reasonable to at least handle the ParseError better to indicate that the user might want to change their markupTagName configuration?