[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: |
|
||||||||||||
| 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:
|
| 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:
|
| Comment by Robert Kowalski [ 16/Feb/17 ] |
|
best practice:
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.
|
| Comment by Robert Kowalski [ 17/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? 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. |
| 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 light-projects are at: https://github.com/robertkowalski/mgnl-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 |