I was playing around with Svelte, trying to integrate it with Meteor. Then, by accident, I found svelte:compiler by @klaussner, which already compiles Svelte-components into Javascript. What a pleasant surprise!
It works just fine, but when I was making changes to the package so I could use PostCSS inside Svelte’s <style></style> -tags, I noticed the plugin is using Babel to compile Javascript .
I thought it’s up to the app’s developer to either include ecmascript package or not
Thinking I could just remove the Babel.compile step, I refactored the code to just use the Svelte-compiler’s result instead. After all, the package includes ecmascript as does my test app too.
To my surprise, I got ES6 code shipped to the browser and naturally some syntax errors followed.
I wonder if some helpful soul could maybe explain what’s wrong with my thinking in how the build system works regarding code transpilation?
(The documenation on Meteor’s plugin system is really scarce)
Meteor is using Babel to compile JavaScript and build bundles.
ecmascript package allows you to use es2015+ in your code and then it will use Babel to compile it to cjs that a browser can read (either modern or old bundle in Meteor 1.7).
I’m not familiar with what Svelte compiler does so I can’t comment, but bear in mind that the Meteor Babel compiler is adjusted from the regular Babel. The ecmascript package is not going to work as it is designed to hook into the Babel compiler.
My guess is that by removing Meteor Babel compiler ecmascript package isn’t working (point 3). Unless the Svetle compiler in some way handles that it will be set as is to the client.
Those are my initial thoughts from my knowledge of things. I have not played so deeply with the build system so take what I said with grain of salt.
The expert is @benjamn so he will be the guy that can tell you how and why.
@storyteller thanks for chiming in with your thoughts. I have a pretty good idea on why we need the ecmascript package and what it does – my confusion was more about how ecmascript operates when used by another build plugin or the app itself.
To simplify my apparently false assumption: I thought including the ecmascript package to my app would force all JavaScript to get transpiled into ES5 and that other build plugins, may it be ones compiling Svelte-templates or Blaze-templates or something else to JavaScript, would not need to explicitly call Babel.compile on the code bits they add to the pipeline.
Other packages can use the babel-compiler package to (help) implement their own compiler plugins, too.
A good model for writing a compiler plugin that uses babel-compiler is the coffeescript-compiler package, which generates modern ES2015+ code first, and then uses its own instance of BabelCompiler to handle the remaining compilation, automatically taking into account the needs of modern browsers, legacy browsers, and Node:
Note, however, that only one compiler plugin can handle a given file extension, so you might not be able to use both ecmascript and svelte:core, if both try to handle .js files. If you delegate .js compilation to babel-compiler, though, you might be able to replace ecmascript with svelte:core without having to reimplement too much of the Babel compilation pipeline yourself.
Thanks for the insight @benjamn ! I believe I get it now:
The svelte:compiler (which uses svelte:core ) handles only .html files, which get compiled into JS, but that code will not be touched again by the babel-compiler via the app’s ecmascript package, even though it handles the .js files. For that to happen, the files should be .js in the first place, and then we would have the suffix-clash you mentioned.
This means that the svelte:compiler has to take care of the full journey of a Svelte-template (which is fully contained inside a .html file, single-file-component-style) into browser-friendly JS, with the help of babel-compiler or something equivalent, even if the app itself uses the ecmascript package.
And then again, using ecmascript in the svelte:compiler or svelte:core -packages only means you can use modern JavaScript in that package’s code, it doesn’t “intercept” any code handled by the compiler inside the package.
I’m relieved that I think I understand, but if I got it wrong, don’t be afraid to bring me down
Thank you! Next stop: deep dive into the coffeescript package.
To my surprise, I got ES6 code shipped to the browser and naturally some syntax errors followed.
Next stop: deep dive into the coffeescript package.
