During Liferay DEVCON 2015 some interesting topics spurred out of the new Liferay Theme build process.
This document, and the expected following discussion, is here to understand how we can guarantee for web front-end engineers a friendly development environment and a de-facto standards adherent runtime.
At Liferay DEVCON 2015 a new way to build Liferay Themes has been announced. It is built around gulp tasks and offers the concept of Themelets, composable features distributable through npm. Themelets are then merged in your own theme at build time.
No explicit statement from the user (other than the installation of the Themelet itself) is required for the changes to take effect. The build process owns the concept of Themelets.
The discussion started around the fact that while Themelets are distributed through npm, they are not good npm citizens, we are using npm as a centralized storage system with a nice retrieval and versioning command-line util.
What a front-end engineer would expect is something different, and that’s dependency management. A small piece of code is worth a thousand words:
// liferay-themelet-sticky-dockbar/index.js
import Sticky from 'a-sticky-polyfill-on-npm';
export default new Sticky('#dockbar');
// liferay-themelet-sticky-dockbar/package.json
{
"name": "liferay-themelet-sticky-dockbar",
"version": "0.1.0",
"dependencies": {
"a-sticky-polyfill-on-npm": "^1.0.2"
}
}
This is currently out of scope of the new Theme build process.
We think it should and that it should encompass the whole front-end development experience on Liferay.
- Let front-end engineers use their favorite package manager for Liferay Themes and Apps (aka Portlets) development.
- Provide a preferred distribution path for Liferay-oriented packages (e.g. Themelets.)
- Guarantee the support for current common scenarios (e.g. deduplication of packages, conflict management), common practices (polyfills, global-pulluting-things) and libraries/frameworks (e.g. Metal.js, Angular, React).
- Identify the module system to be used and define eventual compatibility paths.
- Define the boundaries for forward-compatibility of the designed system.
- OSGi™ Alliance — RFP-171 Web Resources (PDF) (ODT)
- Node.js module resolution algorithm
- Bower definition file specification, aka
bower.json
- Webpack, web-oriented «module loader»
- Browserify, «[…] lets you require('modules') in the browser by bundling up all of your dependencies»
- Rollup, «Next-generation ES6 module bundler»
- SystemJS Build Tool, «Provides a single-file build for SystemJS of mixed-dependency module trees»
- module-deps, static analyzer that «walk[s] the dependency graph to generate json output […]»
- Liferay’s AMD Loader
- SystemJS, «Universal dynamic module loader»
- Require.js, «[…] file and module loader»
- Browserify’s browser-pack, actually a bundler that provides a single-file module registry and loading runtime
- Webpack’s resource (custom or non-js) loaders list
- Webpack’s code-splitting features
- Webpack’s comparison page
Summary of Request:
Brief description of request that all stakeholders can agree to.
Details of Request:
Customer list of the things necessary to accomplish the end result.
Affected Components:
What existing components are impacted by this request?
Work Involved:
High level definition of the desired API, classes, and SQL to be implemented.
Acceptance Testing:
Defined methodology for testing the items listed in the Details of Request section.