Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break out individual compilers #1678

Open
Rich-Harris opened this issue Aug 23, 2018 · 5 comments
Open

Break out individual compilers #1678

Rich-Harris opened this issue Aug 23, 2018 · 5 comments
Labels
compiler Changes relating to the compiler
Milestone

Comments

@Rich-Harris
Copy link
Member

Rich-Harris commented Aug 23, 2018

As frequenters of the Discord server will know, I'm become obsessed lately with the idea of compiling Svelte components to WebGL code (not for UI, but for building 3D/VR scenes — the sort of thing you'd traditionally use Three.js or A-Frame for). The easiest way to try this out would be to create a new compile target inside Svelte itself, but that would be somewhat disruptive for something that may turn out to be completely impossible.

An alternative, which I think is worth doing anyway as it would be good for the codebase, is to break out different compilers into their own packages. So instead of every Node subclass implementing build (for the dom target) and ssr (for the ssr target), the program generated in the initial phase would be handed off to a compiler, which would return something like a { code, map } object (or otherwise something that can be easily turned into one, if that makes more sense in terms of code reuse etc).

So we'd have @sveltejs/compile-dom, @sveltejs/compile-ssr and (eventually) @sveltejs/compile-gl, each implementing the same interface. In time we could even add to that list — @sveltejs/compile-native, @sveltejs/compile-tty and so on.

In all likelihood this would need to be accompanied by separate runtime libraries for the different targets — @sveltejs/lib-dom, @sveltejs/lib-ssr, @sveltejs/lib-common (which dom and ssr would re-export from).

Aside from all the speculative VR stuff, I think this would probably make the codebase less intimidating for new contributors, and it would be good discipline. (The svelte package would still bundle everything, we wouldn't have a nightmarish situation with peer dependencies getting out of sync.)

Any thoughts?

@acstll
Copy link
Contributor

acstll commented Aug 23, 2018

Aside from all the speculative VR stuff, I think this would probably make the codebase less intimidating for new contributors, and it would be good discipline.

Yes please :)

@arxpoetica
Copy link
Member

You have my full blessing. I love the heck out of this.

@pngwn pngwn added compiler Changes relating to the compiler temp-stale and removed internals labels Jun 26, 2021
@benmccann benmccann added this to the 4.x milestone Sep 9, 2021
@schneiderfelipe
Copy link

👍🏽 yes, please! 🎉
I would love to see a @sveltejs/compile-tty be Svelte's vadimdemedes/ink.

@stalkerg
Copy link
Contributor

@benmccann what exactly remains? As I can see Rich has already done the main things.

@connorgmeehan
Copy link

What would we expect the API to look like? From what I can see we can pass in a new compiler in src/compiler/compile/index.js. Could we make the generateoption also to take a function that is the compiler, receiving the same options as this line of code (I can PR this + add typings).

I am also interested in using svelte for pixi or three js so I'm pretty curious about how you'd mix and match components so that some are compiled to DOM nodes and some are compiled to three.js objects. Would it be preferred to make a threejs compiler fallback to the default compiler and if so are the correct functions exported?

@dummdidumm dummdidumm modified the milestones: 4.x, one day Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler Changes relating to the compiler
Projects
None yet
Development

No branches or pull requests

10 participants