One of the biggest issues/complaints I've seen with the asset-pipeline is managing the include exclude patterns of assets that actually need compiled vs. assets that don't. There seems to be no easy silver bullet solution to this as everyone's code structure is different but there are some things we can do that may help ease the burdon. I would like to introduce a concept of an extensible
ScanFilter could be registered by any plugin (similar to how
AssetProcessor) and added to the pipeline that scans for files to include/exclude from a build.
A great example usecase for this might be a bower aware asset-pipeline module that could read a packages.json file and appropriately omit / include files specified in the json file without having to compile the entire set of source files. This wouldn't even be that hard of an add to asset-pipeline and could facilitate other package managers down the line. Another extensibility feature related to this might also be to allow an
AssetFile object to confirm a file match not simply by an extension but also by the contents of the file.
One of the issues that has cropped up with the newer version (at least in the context of Gradle) is that configuration has to be duplicated between runtime and build time. Finding a solution that moves this to one clear cut place would significantly improve the use of the plugin and reduce confusion.
The gradle plugin for the asset-pipeline was primarily built to support the release of Grails 3 and still could use some improvements. On that list is forking the
AssetCompile process into its own java process. This should relieve some memory pressure running inside the gradle jvm and reduce clutter on the class path.
While there is a prototype early stages
spring-boot plugin for the asset-pipeline it could still use some work to improve referencing assets from within the view layer as well as build time injection.
ratpack from some headway has been made on using a Guice module with a custom handler to make runtime support run perfectly. This still needs a lot of work to be ready for use by a team on Ratpack and I plan to focus on this very soon.
These are some of the items that need to be addressed in the new asset-pipeline. Contributions are definitely welcome to the project as the code base grows. If you find yourself wanting to contribute things not on this list such as maybe Typescript support or Dart support feel free to build addon libraries using the extensibility guide for the asset-pipeline.