[NPMCLI-79] Light Project support Created: 25/Jan/17  Updated: 26/Feb/17  Resolved: 22/Feb/17

Status: Closed
Project: Magnolia CLI
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Neutral
Reporter: Christopher Zimmermann Assignee: Robert Kowalski
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to NPMCLI-38 Use resources from other npm packages... Closed
is related to NPMCLI-71 LESS and SASS: Identify best practices Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: CLI: Resource handling
Sprint: Basel 84
Story Points: 5

 Description   

Help developers working on a web project based on light modules: a "Light Project".

Document best practices, provide examples, and integrate support for these in the CLI. We already provide support for light modules, but some things need to be handled specifically at the project level.

Key things to address:

  • Getting and using web resources that are in 3rd party npm packages.
  • Project level web esource processing - less, sass, concatonation, minification, js transpilation, sprite processing, etc. Especially on the project level, for example bundling css and js into site.js and site.js. (Gulp/grunt/webpack tasks)
  • Project structure
  • Project-level configuration


 Comments   
Comment by Christopher Zimmermann [ 25/Jan/17 ]

For an example of a project which addresses some of these concerns see: https://github.com/Kaivosukeltaja/frog-rain

Comment by Robert Kowalski [ 16/Feb/17 ]

LESS, TS, ES6 etc should be end up compiled in /webresources/ to make further build more predictable.

Comment by Robert Kowalski [ 16/Feb/17 ]

for multi-light-module projects webpack is sadly not very well suited.

as it is all about bundling everything into one or multiple files, the API requires us to define an entry point for the resolver and also a target for the (in this case not needed) bundle.

Comment by Christopher Zimmermann [ 16/Feb/17 ]

re webpack - and it would not work or would be nonsense to give it some stubs/fake locations in the directory where the webpack config lives?

Comment by Robert Kowalski [ 16/Feb/17 ]

hm not for this use case, its just not the right tool for the job i think

Comment by Robert Kowalski [ 16/Feb/17 ]

best practice: avoid using refsn directly in your component's template.

reasons:

  • makes CDN usage possible.
  • "multi-light-module-projects" can concatenate the JS/styles to one bundle.
Comment by Robert Kowalski [ 16/Feb/17 ]

best practice:

  • a light module should compile assets to webresources/
  • by convention via `npm run build`

reasons:

Multiple parties (friends, colleagues, scrum teams in one company) share modules. They all use other transpilers: LESS, SASS, Stylus, PostCSS, TypeScript, Coffeescript, ES6, Babel ES6 with experimental ES7 features.

With a convention how to start a build on module and a common destination for the results (always CSS / JS) consumer can just iterate over all lightmodules, run the build step and then concat the results in their own project.

  • It also leaves the build script for a multi-module-project very lean and easy to maintain (no need to add another transpiler plugin as soon as you pull in another module.
  • No need to change the build when one dependency switches to another transpiler.
  • No need compability issues, e.g. there is no PostCSS plugin for gulp, and the dependend project was build with webpack.
Comment by Robert Kowalski [ 17/Feb/17 ]

czimmermann:

re webpack - and it would not work or would be nonsense to give it some stubs/fake locations in the directory where the webpack config lives?

after our meeting yesterday i think i wasn't right. it is possible and it could even become very cool:

https://github.com/robertkowalski/mgnl-super-furbie

I took a look at the webpack loader spec today and we could remove some annoying things with a LightModule Loader for Webpack.

Comment by Christopher Zimmermann [ 20/Feb/17 ]

LightModule loader for webpack sounds nice.
Yeah - I was going to say it would be nice if there was a way to tidy up some of the boilerplatey stuff in another support package.

Comment by Robert Kowalski [ 21/Feb/17 ]

results from comparing the webpack and gulp based approach:

The gulp based approach is easier to understand for JS newcomers. Experienced users will ask if using webpack is possible, which it is. Someone who is more experienced can use a webpack based build.

Regarding the main example we are going with gulp. Whitelisting the files needed for the build is easier than maintaining a blacklist. The scoffolded fodlers for a light-module are always the same while the amount of folders and files by modern frontend tooling is ever changing.

An open question is still Getting and using web resources that are in 3rd party npm packages. which is tracked an covered separately in NPMCLI-98

light-projects are at:

https://github.com/robertkowalski/mgnl-furbie
https://github.com/robertkowalski/mgnl-super-furbie

Comment by Christopher Zimmermann [ 21/Feb/17 ]

Note that now we see most of the web resource processing and the 3rd party dependency being solved at the module level with a module build - so its not necessary to handle at the project level. The project build is simply about getting and optionally combining webresources already generated by the module builds.

Last and final step is a gulp process to get and process webresources from the modules defined in the package.json "dependencies" section, with a minimum of extra config - without need of "configure" file. And to document here: https://wiki.magnolia-cms.com/display/PMTEAM/Conclusions+on+light+module+on+npm+topics

Comment by Robert Kowalski [ 22/Feb/17 ]

the configure-script was removed in https://github.com/robertkowalski/mgnl-furbie/commit/32d47b80b9a36f0f78e6bc4025f0e4b5e2a2d86c

Generated at Mon Feb 12 04:46:19 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.