Open arigoldx opened 4 years ago
There's definitely a tradeoff here. My short assessment is that it will probably take somewhat less time to adapt this to latest sbt than to move a whole setup to a newer JS packager. The upside of a newer JS packager is the potential to leverage things like TypeScript directly in the build pipeline (though that could also be added here).
Long term there are gains to be had from using what the JS community is using. Shorter term it's probably easier to port this.
That said, I seem to recall there were some major API changes in sbt, so you could be looking at a bunch of spelunking.
Thanks for that. Have to pivot to other tasks but when I circle round again I'm going to work on adapt this to the latest sbt 'cause it's less new stuff and, ergo, less moving parts.
I'll post again.. or maybe open a PR! 😲
Hi there,
As most of y'all know, here at Elemica we use sbt-resource-management. Trick is, we want to upgrade to the latest
sbt
(1.3.9) and right now have to figure out whether to updatesbt-resource-management
or, well, do something else.For some reason I have a note that links to this project but says "better to use grunt instead of rewrite sbt-resource-management". Sadly, I didn't write down why we should use grunt.
Any ideas or suggestions here?
Part of me thinks that we should update
sbt-resource-management
to sbt 1.3.9 because it's what we're currently using. It's how our markup connects to JavaScript and CSS ergo, moving away fromsbt-resource-management
implies quite a bit of work (like reworking of all of our markup).On the other hand, maybe the aforementioned reworking is worth it. Heck, maybe one of y'all are the ones who suggested using grunt instead.
I figured I'd check in before starting The Production:tm: :)
Thanks!