Allow separated input of HTML, CSS and JS in addition of Single File Components

[cj]

I have briefly looked over all the docs, I really like the direction svelte has taken. Quick question, can the compiler handle <script src="hello.js"> so that you can split the javascript into a separate file and not have everything in hello.html?

[proyb6]

If JS is serve in the production, a single file is easier and efficient. Do you mean

page1.html to page1.js - link to index.html
page2.html to page2.js - link to aboutus.html
page3.html to page3.js - link to contactus.html

Would be possible to compile in a different folders or filename which I'll be achieving my blogs with this method.

[Rich-Harris]

The compiler needs to be able to 'see' the JS and the markup at the same time so that it can do various bits of analysis. So for now, that step would have to happen in a preprocesser that read the <script src='hello.js'>, resolved hello.js, loaded it, and injected it into the template.

It's possible we might want to add that in core at some point – I'll flag this issue with the 'enhancement' label.

[cj]

@Rich-Harris The same would go for the <style> tag. I guess the best example of this would be vue-loader https://vue-loader.vuejs.org/en/start/spec.html#src-imports. Having the ability to choose the pre-processing language would be a good idea too.

[rhengles]

I want to point out that there are two different ways this can be done, and maybe supported.

One is the original proposed by @cj - using tags with the paths to the external files.

The other is passing directly each file to the compiler, without need of tags. As an example, in my (Vue) project I have a convention of creating three files like this: <component-name>.(html|js|css). So I would load them directly into the compiler, without need of repeating the js and css file paths in all components.

[Conduitry]

I'm kind of a fan of having the core compiler providing only a method that takes separate HTML, JS, and CSS - and to leave things like looking for script and style and link tags (and accessing external files) to external tools. This is an even lower-level API than the compiler provides now, so this would obviously be a breaking change.

I've used tools before where the lowest-level API that's exposed still makes assumptions about your setup (e.g., that things are coming from physical files on the disk), and it's not fun. I definitely want to avoid that here. I don't want svelte.compile to start doing disk access.

[arxpoetica]

What about importing just js files in the case where a component is literally just js?

import AudioService from `./services/AudioService.js`

I've already broken out my precompile processes via my own npm script methodology, but occasionally I find myself with only a js file, and some boilerplate HTML file just to load the js script.

https://svelte.technology/repl?version=1.38.0&gist=3f3260fa442911b8f78d13d0a0f12eeb

Catch my drift?

[EsmeraldiBejolli]

@Rich-Harris I'm using path to script tag that point to external file but data are still unresolved and I get undefined instead of resolving placeholder on svelte template .

`

Have you tried Svelte? It's {{adjective}}.

<script type="text/javascript" src="./Test1.js"> </script>`

Thank you in advance

[kaisermann]

Allowing to define a external src file would help a lot while we don't have IDE extensions for svelte:

vs

[kaisermann]

Oh, you can, at least for styles, do this with the preprocess property. Quick example:

Edit:

I've made a little lib to help with this

[ghost]

this works with JS

<script>
  import test from './test.js';
  let name = `${test} 'world'`;
</script>

<h1>Hello {name}!</h1>

[kaisermann]

I think this is safe to close this issue since separating a component style and script is completely covered by preprocessors, which usually implement this behavior. @pngwn @Conduitry

[antony]

@pngwn I think we should close this. Is there a reason you wanted to keep it open?

[pngwn]

I don't fully remember, I think I closed it and someone told/asked me to keep it open, which is why it got reopened quickly after closing.

[antony]

It's on Rich's roadmap, I later discovered. I might close it here and add a pure roadmap item for it.

On Thu, 9 Apr 2020 at 19:58, pngwn ***@***.***> wrote: I don't fully remember, I think I closed it and someone told/asked me to keep it open, which is why it got reopened quickly after closing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABVORJ5UYLCVL6NDL7RRMDRLYLDTANCNFSM4CYBWVMA> .

--

…

________________________________ ꜽ . antony jones . http://www.enzy.org

[pngwn]

I'm not sure Rich is actually in favour of this any more, I feel like I remember this conversation because this has been discussed quite a lot over the past year or so but you'll have to ask him to be certain.

[antony]

I'll have a word.

On Thu, 9 Apr 2020 at 20:05, pngwn ***@***.***> wrote: I'm not sure Rich is actually in favour of this any more, I feel like I remember this conversation because this has been discussed quite a lot over the past year or so but you'll have to ask him to be certain. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABVORO4QIDSJVDHXPCYODTRLYMA7ANCNFSM4CYBWVMA> .

--

…

________________________________ ꜽ . antony jones . http://www.enzy.org

[antony]

This can be done via https://github.com/kaisermann/svelte-preprocess - and as such, isn't planned for core.