this would give users more flexibility when setting up tests or other tooling where they want to compile runes but the .svelte.js convention would go against another convention (.test.js).
You have to allow .svelte.test.js on our end or .test.svelte.js on the test end. Given we are defining a new file format, making it play nice with existing ones feels like its the better way.
Right now this is not limited to the second last segment, So foo.svelte.bar.baz.qoox.js matches too.
While doing this i saw that custom extensions were also used for prebundling. This has been removed because prebundling is only for libraries and these should never use custom extensions, otherwise we end up with fragmentation on the registry where users have to customize their svelte config to consume a library.
dominikg
commented
1 month ago
and prevent custom extension prebundling
this would give users more flexibility when setting up tests or other tooling where they want to compile runes but the
.svelte.jsconvention would go against another convention (.test.js).You have to allow
.svelte.test.json our end or.test.svelte.json the test end. Given we are defining a new file format, making it play nice with existing ones feels like its the better way.Right now this is not limited to the second last segment, So
foo.svelte.bar.baz.qoox.jsmatches too.While doing this i saw that custom extensions were also used for prebundling. This has been removed because prebundling is only for libraries and these should never use custom extensions, otherwise we end up with fragmentation on the registry where users have to customize their svelte config to consume a library.