sbt-web 1.0.0-M1 is available

[Christopher Hunt]

A milestone of sbt-web is now available. sbt-web will factor out JS tooling concerns from Play such as LESS, JSHint, CoffeeScript and others. In addition its architecture enables the community to contribute JS tools. 

One of the prime benefits of sbt-web is native performance. By default the JS tools execute within the JVM using Trireme which is the Node API on top of Rhino. However if you have Node.js installed then you make one setting change in your build file and achieve Node performance.

For more information on sbt-web: https://github.com/typesafehub/sbt-web#sbt-web

sbt-web will be automatically included with Play 2.3. However if you would like to use it with your existing version of Play then you should be able to. The following instructions have been applied successfully to a Play 2.2 project:

1. For each js tool that is require you need to bring in its plugin. For example for JSHint, add the following to your project/plugins.sbt:

addSbtPlugin("com.typesafe" %% "sbt-jshint-plugin" % "1.0.0-M1")

sbt-less-plugin is also available at this time.

2. You will probably require the following imports in your build file e.g. build.sbt:

import com.typesafe.web.sbt.WebPlugin
import com.typesafe.jse.sbt.JsEnginePlugin
import com.typesafe.web.sbt.WebPlugin.WebKeys

3. Bring in the sbt-web settings to your build file:

WebPlugin.webSettings

JsEnginePlugin.jsEngineSettings

4. Further down the build file you need to bring in the requisite settings in order to convey Play's directory structure to sbt-web:

sourceDirectory in WebKeys.Assets := (sourceDirectory in Compile).value / "assets"

WebKeys.jsFilter in WebKeys.Assets := new PatternFilter("""[^_].*\.js""".r.pattern)

resourceDirectory in WebKeys.Assets := (baseDirectory in Compile).value / "public"

resourceManaged in WebKeys.Assets := (classDirectory in Compile).value / "public"

5. For every js tool required you need to import and declare their settings:

import com.typesafe.jshint.sbt.JSHintPlugin

JSHintPlugin.jshintSettings

in addition (for the LESS plugin), you should disable Play's built-in LESS compiler:

lessEntryPoints := file("")

***

Please note that steps 2, 3 and 4 will not be required in Play 2.3 as these things will be done automatically.

Have fun!

Kind regards,

Christopher

-- 
Christopher Hunt
Senior Engineer
Typesafe – Build Reactive Apps on the JVM!

Twitter: @huntchr

[Anton Kulaga]

What about the most desirable feature, ScalaJS support, is it in your roadmap?

What about nonJS things like Saas+Compass, do you also have plans about them (I know there is play-sass plugin but its last update is 7 months old and it is buggy)?

[Christopher Hunt]

On Friday, 31 January 2014 12:47:40 UTC+1, Anton Kulaga wrote:

What about the most desirable feature, ScalaJS support, is it in your roadmap?

The initial focus is to achieve feature parity with Play today i.e. LESS, CoffeeScript, RequireJs minification, code verification (JSHint). We're hopeful that the community will get onboard and also provide plugins, although we probably have some more work to do in order to make that process smoother.

 

What about nonJS things like Saas+Compass, do you also have plans about them (I know there is play-sass plugin but its last update is 7 months old and it is buggy)?

It is all entirely doable. :-) Once Play 2.3 is delivered then I think we may be able to determine what should be next along with priorities etc. There is probably a sweet spot of tools that we can target. Another thought is to integrate npm with sbt-web so that we can get Node related artifacts without having to form a WebJar. This will make writing sbt-web plugins even easier.

[Julien Richard-Foy]

Is there a plugin handling webjars?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Julien Richard-Foy]

Is there any roadmap available somewhere?

I’d love to have an integrated build system handling my client-side libraries dependencies and my JavaScript code minification and concatenation. Like grunt/bower, but with just sbt (because my Play application is built with sbt anyway).

[Christopher Hunt]

> On 5 Feb 2014, at 8:17 pm, Julien Richard-Foy <j...@zengularity.com> wrote:
>
> Is there a plugin handling webjars

https://github.com/webjars/webjars-play

[Christopher Hunt]

> On 5 Feb 2014, at 8:20 pm, Julien Richard-Foy <j...@zengularity.com> wrote:
>
> Is there any roadmap available somewhere?
https://docs.google.com/a/typesafe.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA/pub

> I’d love to have an integrated build system handling my client-side libraries dependencies and my JavaScript code minification and concatenation. Like grunt/bower, but with just sbt (because my Play application is built with sbt anyway).

This isn't on our 2.3 roadmap, but the bones are there. We may be able to get this done and I think it would please quite a few people.

Incidentally I got NPM working from sbt over the w/e...

[Christopher Hunt]

Just a quick update on where sbt-web is up to.

We intend to release a second milestone in the next week or so and things are shaping up very nicely. There's been a ton of work under the hood in ensuring that sbt-web provides a solid foundation to build browser based applications on. I'm particularly excited about how sbt-web plugin authoring has been massively simplified by putting a greater emphasis on the JS authoring requirements. I think this approach will resonate well with the JS community and hopefully encourage sbt-web's community to contribute the best JS tool plugins on the planet.

Another development is along the lines of NPM. We've now got NPM working on the JVM... this means that we can integrate it with sbt along with WebJars. Next stop: Bower. This will mean that web artifacts for your projects can be sourced from WebJars, NPM and/or Bower - mix it up as much as you need!

The asset pipeline foundations are in place and we'll be building that out further. Finally our JS testing approaching is shaping up very nicely and may even make milestone 2.

Exciting times and more to come!

Kind regards,

Christopher

[naturallog]

This is great news and i have been looking forward to this ever since i saw the pingconf video.

I am currently building an app with angularjs frontend and play as json backend (also serving all the assets).  I am using the excellent 'play-yeoman' sbt plugin to manage my frontend using grunt.

What would be the recommended approach for such an app when using sbt-web. In particular, i wouldnt want to use requirejs.

[Christopher Hunt]

Firstly let me re-state that we should look toward supporting GruntJs directly using sbt-web. I think this can be done such that Grunt tasks can be invoked from within sbt. However this approach probably won't integrate as well as plugins specifically targeting sbt-web. The GruntJs integration would probably not have any incremental execution, integrated logging and more...

It should be possible to avoid the need to use Yo/GruntJs in your particular use case. That said, what GruntJs plugins are you using?

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/YLPAEnaE0FE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.

[naturallog]

I am using https://github.com/tuplejump/play-yeoman. 

This already couples grunt to play and allows invoking grunt tasks from within sbt and also integrates grunt packaging commands with stage, dist etc.

If the sbt-web based asset pipeline can handle jshint, asset minification, running tests etc., then i would need only few other gruntjs plugin functionality like ngMin.

I would prefer an all sbt solution (like rails asset pipeline) and avoid grunt if possible

[Yann Simon]

Hi Christopher,

some questions:

- do you support stream pipelines, like gulp? For example:

unmanagedSources -> coffeescript parser -> lint -> minify plugin -> resourceManaged

- if I want to build a plugin for example for reactjs (jsx -> javascript), where should I start?

Do you have any examples of existing plugins that use sbt-web?

Thanks in advance,

Yann

[Christopher Hunt]

some questions:

- do you support stream pipelines, like gulp? For example:

unmanagedSources -> coffeescript parser -> lint -> minify plugin -> resourceManaged

Yes we do!

Plugins are divided into a few categories:

* Source file plugins (coffee script, LESS etc)

* Asset pipeline plugins (RequireJS, digest etc)

* Test plugins

One interesting difference is that source file plugins execute in parallel. Asset pipeline plugins execute serially and in a specified order.

- if I want to build a plugin for example for reactjs (jsx -> javascript), where should I start?

Do you have any examples of existing plugins that use sbt-web?

The LESS plugin is a good one to start with. I've just applied some massive re-factoring to it. I intend to publish M2 this week so let me do that and then base your work on it perhaps.

Thanks for the interest!

Kind regards

Christopher

Thanks in advance,

Yann

Le samedi 1 mars 2014 10:10:14 UTC+1, Christopher Hunt a écrit :

Just a quick update on where sbt-web is up to.

We intend to release a second milestone in the next week or so and things are shaping up very nicely. There's been a ton of work under the hood in ensuring that sbt-web provides a solid foundation to build browser based applications on. I'm particularly excited about how sbt-web plugin authoring has been massively simplified by putting a greater emphasis on the JS authoring requirements. I think this approach will resonate well with the JS community and hopefully encourage sbt-web's community to contribute the best JS tool plugins on the planet.

Another development is along the lines of NPM. We've now got NPM working on the JVM... this means that we can integrate it with sbt along with WebJars. Next stop: Bower. This will mean that web artifacts for your projects can be sourced from WebJars, NPM and/or Bower - mix it up as much as you need!

The asset pipeline foundations are in place and we'll be building that out further. Finally our JS testing approaching is shaping up very nicely and may even make milestone 2.

Exciting times and more to come!

Kind regards,

Christopher

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/YLPAEnaE0FE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.

[Yann Simon]

2014-03-04 19:44 GMT+01:00 Christopher Hunt <christop...@typesafe.com>:
>
> some questions:
> - do you support stream pipelines, like gulp? For example:
> unmanagedSources -> coffeescript parser -> lint -> minify plugin ->
> resourceManaged
>
> Yes we do!
>
> Plugins are divided into a few categories:
>
> * Source file plugins (coffee script, LESS etc)
> * Asset pipeline plugins (RequireJS, digest etc)
> * Test plugins
>
> One interesting difference is that source file plugins execute in parallel.
> Asset pipeline plugins execute serially and in a specified order.

Good to know.

>
>
> - if I want to build a plugin for example for reactjs (jsx -> javascript),
> where should I start?
> Do you have any examples of existing plugins that use sbt-web?
>
> The LESS plugin is a good one to start with. I've just applied some massive
> re-factoring to it. I intend to publish M2 this week so let me do that and
> then base your work on it perhaps.
>
> Thanks for the interest!

A little notice: I think it would help if you link the different
plugins (LESS...) directly on the sbt-web page:
https://github.com/sbt/sbt-web
(or on the wiki)

> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Christopher Hunt]

Good idea. I'll attempt to maintain a list of related plugins from sbt-web's README.

Thanks.

[Andrew Gaydenko]

Heh... I don't use LESS, RequireJS, CoffeeScript, Grunt... But I use other tools (sass, gulp, webpack) in form of, at the moment, four constantly running watchers (two gulps and two webpacks processes for different Play subprojects). All the chain is: In Eclipse I hit Ctrl-S, watcher(s) takes changes and produce something in /public, sbt (being in ~run) takes changes in /public.

I don't say above scenario is cumbersome or unhandy (in fact, it is just a script starting terminal session with detached processes). But probably sbt-web will some days take care of  such Node-oriented watcher in some form.

[laguiz]

+1 for NPM and Bower

[Christopher Hunt]

Just on NPM, we now have support for NPM in sbt-web - we'll hopefully get another milestone out very soon.

On 21/03/2014, at 9:36 AM, laguiz <war...@gmail.com> wrote:

+1 for NPM and Bower

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/YLPAEnaE0FE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[naturallog]

Is the second milestone near ?

On Saturday, March 1, 2014 2:40:14 PM UTC+5:30, Christopher Hunt wrote:

[Christopher Hunt]

Hopefully. :-)

I'm finishing off the RequireJS plugin - it is quite involved as I'm trying to automatically provide CDN translations for WebJars.

We're also relying on some sbt features that are yet to be released.

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/YLPAEnaE0FE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[naturallog]

Just saw that autoplugins is rolled back from 0.13.2 - https://groups.google.com/d/msg/sbt-dev/24uassbKyuA/X2iPEReHpU4J

[Julien Richard-Foy]

Hi,

On Friday, March 21, 2014 3:33:37 AM UTC+1, Christopher Hunt wrote:

Just on NPM, we now have support for NPM in sbt-web - we'll hopefully get another milestone out very soon.

 That’s not completely clear to me, what do you exactly mean by “support for NPM”? Is it possible to easily execute npm commands from sbt? Is this documented somewhere? I’d like to use npm packages instead of webjars to manage my client-side libraries, how can I do that?

Cheers,

Julien

[Christopher Hunt]

Hi Julien,

There's a bit of doco here:

https://github.com/sbt/sbt-js-engine#npm

I've also improved the Play 2.3 doco for npm but I've not pushed those changes yet; I'm just finishing off a PR that includes this doco.

Kind regards,

Christopher

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/YLPAEnaE0FE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Christopher Hunt
Senior Engineer
Typesafe – Build Reactive Apps on the JVM!

Twitter: @huntchr

JOIN US. REGISTER TODAY!

Scala

Days

June 16th-18th,

Berlin

[Julien Richard-Foy]

Hi, thanks for the pointer.

I’m not sure it is good to keep the use of a package.json file besides
the build.sbt file, since they are partially redundant.

Do you differentiate between dependencies and devDependencies?

Do you think it would be feasible to build an ivy2 repository proxying
the nmp registry? Kind of an automated webjars repository.

[Christopher Hunt]

Hi Julien,

I originally looked at providing a resolver for NPM artefacts and concluded that it wouldn't be easy. I'd prefer to invest time in integrating WebJars with npm i.e. extending npm to publish WebJars.

package.json is required because what we're actually doing is calling npm programmatically and either running it in-JVM via Trireme or on Node. I personally wouldn't look forward to reproducing npm's logic elsewhere.

Another use-case is one that I learnt from an organisation where they have both JS devs and Scala devs on the one project. The JS devs prefer to use GruntJs, the Scala devs are happy with sbt. However the Scala devs want the consolidated build and found it a pain to jump between terminal sessions when they want to do a full build - it was quite manual. The situation now is that npm can be invoked from within the sbt build; as a task.

HTH.

Kind regards,

Christopher

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/YLPAEnaE0FE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julien Richard-Foy]

> I originally looked at providing a resolver for NPM artefacts and concluded
> that it wouldn't be easy. I'd prefer to invest time in integrating WebJars
> with npm i.e. extending npm to publish WebJars.

Ok.

> Another use-case is one that I learnt from an organisation where they have
> both JS devs and Scala devs on the one project. The JS devs prefer to use
> GruntJs, the Scala devs are happy with sbt. However the Scala devs want the
> consolidated build and found it a pain to jump between terminal sessions
> when they want to do a full build - it was quite manual. The situation now
> is that npm can be invoked from within the sbt build; as a task.

Ok, that makes sense.

Thanks for your time.

[Xavier Carpentier]

I am very interesting by having SASS support or an official plugin because this a show stopper for play 2.3 migration for me and my client now !  :/

Please :P !

Xavier

[Christopher Hunt]

I agree that saas would be great. Contributions are welcome!

--

[Eric Jain]

On Friday, January 31, 2014 11:08:55 PM UTC-8, Christopher Hunt wrote:

The initial focus is to achieve feature parity with Play today i.e. LESS, CoffeeScript, RequireJs minification, code verification (JSHint).

So I just tried to migrate an application from 2.2 to 2.3, but ran into this: It no longer appears to be possible to do js minification without using RequireJS? This makes it a bit more tricky to use Play to build simple, static, single page apps (i.e. without using Play's runtime templating mechanism)...

[Christopher Hunt]

Yes, we need an sbt-uglify plugin.

--

[ido]

Dear Eric,
is stage working correctly in your case?
I do not get css files (and maybe other files) in the resulting jar.

thank you very much,
ido

[Eric Jain]

On Fri, Jun 6, 2014 at 4:52 AM, ido <idom...@gmail.com> wrote:
> is stage working correctly in your case?
> I do not get css files (and maybe other files) in the resulting jar.

No: My assets jar ends up with the less files instead of the css files
(in dev mode, the less files are compiled as expected)...