Option to compile to ES6 Modules

[hitsthings]

Soy currently compiles to JS globals, which is still a good "least common denominator" choice. Forward-looking projects are already using ES6 modules and transpiling it back to whatever format they like (AMD, CommonJS, globals, whatever). An option to compile to ES6 modules is a good current choice, and in the future will be a better default choice.

[concavelenz]

Not that I'm volunteering, but there are a lot of export options for ES6 modules, would you expect:

1) an simple object containing the file's templates:

export default { someTemplate1(...) { ... }

someTemplate2(...) { ... } };

2) a export per-template

export function someTemplate1(...) { .... };

3) something else?

On Sun, Feb 22, 2015 at 9:15 PM, hitsthings notifications@github.com wrote:

Soy currently compiles to JS globals, which is still a good "least common denominator" choice. Forward-looking projects are already using ES6 modules and transpiling it back to whatever format they like (AMD, CommonJS, globals, whatever). An option to compile to ES6 modules is a good current choice, and in the future will be a better default choice.

— Reply to this email directly or view it on GitHub https://github.com/google/closure-templates/issues/30.

[Ubehebe]

@hitsthings @concavelenz What's the use case? There are clear benefits to writing source code in ES6, as you mention, but it's less clear what the benefits of compiling to ES6 are, other than "all parts of our pipeline should use the latest syntax".

It should eventually happen, but it might not be the highest priority.

[concavelenz]

Native dependency management. On Mar 28, 2015 5:50 AM, "Brendan Linn" notifications@github.com wrote:

@hitsthings https://github.com/hitsthings @concavelenz https://github.com/concavelenz What's the use case? There are clear benefits to writing source code in ES6, as you mention, but it's less clear what the benefits of compiling to ES6 are, other than "all parts of our pipeline should use the latest syntax".

It should eventually happen, but it might not be the highest priority.

— Reply to this email directly or view it on GitHub https://github.com/google/closure-templates/issues/30#issuecomment-87223942 .

[hitsthings]

What's the use case?

Native dep management is one - not having to use goog.require would be good. If the rest of my code is using the AMDish loader of BabelJS, and Soy is using goog.provides, I and every other consumer has to do work to make them play together.

I have a project written in ES6 syntax with a build pipeline that expects ES6 as the source language. My build is either more complicated if I use Soy since I have to exclude it from parts of the build.

It should eventually happen, but it might not be the highest priority.

Fair enough. I wasn't advocating for making it the default, just making it a possibility.

[bradleyayers]

I'm interested in implementing this or #65, but want to know what direction the library maintainers want to take this? Some in-principle support for one approach or the other would be good. At the moment I'm leaning towards AMD.

[b1lly]

bump?

[hitsthings]

FYI, I recently added a modularize option to atlassian-soy-loader. So if you compile with webpack, you can give that package a try. It assumes the Soy namespace in camelCase maps to a module name in kebab-case (but you can override this)

It's a little specific to Atlassian though, as it expects SoyFunctions to be implemented with the Atlassian facade. The code can at least be inspiration though.