Use npm / bower to handle front-end dependencies

[danpolanco]

We originally discussed (gitter) keeping the front-end dependencies as web jars. The reason I wanted to do this was since @itzg is the primary contributor and his language of choice is java, it'd be easier for him to maintain.

As I work with the front-end more, I've found I like decoupling it from java/back-end as much as possible. In that spirit, I'm strongly considering moving the dependencies from web jars, to npm / bower. This is of course up for debate if anyone feels strongly the other way.

I think this will also help as I move forward and start to implement AngularJS tests, and set the front-end up so that I see changes without having to restart the whole server / Spring framework.

[itzg]

I'm pretty flexible about most things, but using webjars is one I'm making a hard stand on...but I can be convinced :). Specifically, if we introduce npm/bower then we now have two artifact management systems at play. You can then argue that the UI could be a project on its own, but other than the unit tests (which is a good point you bring up...more on that in a sec) but then that level of separation is overkill for small to medium projects.

Instead, please look further into leveraging Spring Boot's devtools feature which also brings LiveReload into the picture. In my development work flow I can make a JS/CSS/HTML change, press Ctrl-Shift-S (my particular keymap), and by the time I go to my browser the change is in effect.

Now, back to the Angular unit testing. That's a fantastic idea, so I'd be willing change my beliefs to gain that benefit...however, it looks like I don't have to

https://spring.io/blog/2015/05/19/testing-an-angular-application-angular-js-and-spring-security-part-viii

which I haven't read thoroughly, but I do see it calls out a Maven Jasmine plugin.

[danpolanco]

I defer to your experience since mine is so limited.

The reason I was considering it is because front-end work sometimes feels like the redheaded stepchild. My hope was that by using native tooling I'd be able to work with the UI more fluidly.

A few examples that will / may change as I use Spring more:

• I had to restart the web server so often, but I'll give LiveReload a shot
• errors (e.g. missing dependencies, missing brackets) don't pop out using the spring cli
• there's lots of tooling, tutorials, etc. around the "native" or "traditional" path

I was also hoping such a change would make front-end / back-end work easier since they would literally be separate. For example, bower seems to do a great job taking care of dependencies and centralizes that part of the work. Web jars also work, but feel more clunky? Plus the other nice features of bower.

Again, I don't have much experience so this is all from my naive perspective. Also, much of it is hard to explain since right now it's mostly a gut feeling.

Let's close this for now and instead I'll keep track of what happens that makes me feel this would be more beneficial than harmful.

[itzg]

The only experience part is that Maven has served me well for many years now...other than that it's really just subjective.

What I haven't researched is Maven-Bower plugins. Of course it in turn would need to play nice with Spring Boot and LiveReload since I spend half my time working on UI.

[itzg]

Ok, I had an epiphany: the Bower deps don't change that often, so as long as the artifacts can be staged in a place served by Spring Boot/MVC, then life is good.

The technique of placing the Bower content under src/main/resources/static in this article looks appealing to me.

Want to give that a shot?

[danpolanco]

Hm. Let's push it to 0.2 and then reevaluate. Sound good?

[itzg]

Definitely agree.

[danpolanco]

I'm liking the workflow now :D works well enough for me!