falcon
falcon copied to clipboard
Webpack integration requirements and technical discussion
Summary
The current falcon theme is using the workplace webpack feature to include js (and css?) resources from modules to build single, compact resource file. This scheme needs to be accounted for, e.g. configuration changes or module updates, might need a rebuild via webpack. Since this should be a new technical base for themes, I think it is worth getting deeper into this and discuss about requirements and concept. Hope this is helpful.
Current state
The webpack build includes resources via the workspace feature within package.json
:
"workspaces": [
"../../../modules/*/_theme_dev/"
]
This draws in resources from the Prestashop installation outside of the theme folder.
Requirements
Brainstorming of things that need to be solved:
-
Provide compact JS and CSS files
-
Allow modules to provide JS and CSS resources that are included in one compact file via webpack
-
Allow modules also to use NPM dependencies for resources
-
modules, providing additional resources can be compatible with the classic theme and the falcon theme
-
No extra steps for configuration changes or module updates
-
Have a main and most compact JS file and extended or additional JS files, once additional functionality is used, like the card or faceted search
-
developers can use webpack server feature and changes in modules get picked up
-
no mix of installed and generated files
-
error if installed modules don't match with the theme
Feature target required module/theme
falcon
Drawbacks
time
Hi @cruftex,
this feature has been introduced to simplify development process for theme with modules.
Currently we are fetch every file for specific {workspace}/{entry}/index.(js|scss)
.
What are benefits of that approach - we have access to theme js components, scss variables/mixins/functions via @themeAbstract/index
.
If you developed your store using Falcon with module build this way you can just copy it and paste to another project. Compile assets and everything should be ready to use. Every element will be styled properly since we are using theme variables not variables scoped to module. Of course webpack isn't aware what module is installed/enabled you have to rename your _dev
directory if you want to keep that module in your project directory but don't want to compile that files. (or remove those files entirely)
Provide compact JS and CSS files
Files are already compact
Allow modules to provide JS and CSS resources that are included in one compact file via webpack
I am not sure what you mean. We should be allowed to compile files inside module directory?
Allow modules also to use NPM dependencies for resources
You can use npm for your module via workspaces feature. You can just add any package you want to module package.json. It will be automatically installed in theme node_modules directory. Then you can import it inside your module just like in theme directory.
modules, providing additional resources can be compatible with the classic theme and the falcon theme
I don't want to make those modules compatible with classic theme. It's just extra work and atm we are working on a lot of new stuff like removing jquery and corejs, upgrade to bootstrap 5. There is to much difference between those two themes at this moment.
No extra steps for configuration changes or module updates
You mean like module is being upgraded and you would like to be up to date right away w/o compiling assets via webpack?
Have a main and most compact JS file and extended or additional JS files, once additional functionality is used, like the card or faceted search
I am not sure what you mean?
developers can use webpack server feature and changes in modules get picked up
It's currently working this way.
no mix of installed and generated files
What you mean by no installed or generated files? Generated files are referring to webpack compiled assets? Installed files, those prestashop core modules files for example for productcomments module?
Thank you for taking your time 😉
Provide compact JS and CSS files
Files are already compact
Yes, I tried to gather and write down all requirements that are to be solved to establish the big picture. Sorry for the confusion. I tried to extract "What problems are we trying to solve" as completely as possible and in a neutral, solution agnostic wording to avoid XYPorblems.
modules, providing additional resources can be compatible with the classic theme and the falcon theme
I don't want to make those modules compatible with classic theme.
That's okay, but other module developers might want to and provide a module that is compatible and nice looking with the classic theme and the falcon theme OOTB. For the theme to become successful, it somehow needs to integrate with the existing ecosystem. For example, a payment module might need to be adapted to falcon to integrate the inline form well with the checkout style provided by the theme.
Maybe a simple solution is to check for the existence of the falcon theme and query the version to switch to different HTML, if that is needed.
Maybe there is a general solution for this in PS already?
No extra steps for configuration changes or module updates
You mean like module is being upgraded and you would like to be up to date right away w/o compiling assets via webpack?
Yes.
Right now, new procedures are needed for deployment and upgrades. The theme cannot be deployed or upgraded as every other theme. There are two variants that work now:
- Run webpack on the production server, after relevant modules are upgraded or installed or the theme itself
- build the theme .zip bundle with the relevant modules present, but, I need to make sure that the modules in the shop are consistent with the one I used for the build
The only real "proper" solution I can think of is that webpack needs to be installed along with is_themecore on the production server and is run whenever needed.
The alternative would be to have php code that combines the js and css resources from the modules. But that would duplicate with webpack and is less efficient.
js and css variants depending on stage
I am still looking for a catchy formulation of that.
Have a main and most compact JS file and extended or additional JS files, once additional functionality is used, like the card or faceted search
Rather than having only a complete theme.css and a theme.js, to reduce load time, there would be a more minimal version, e.g. just for the start page. There is a feature in PS to add additional resources, depending on the page: https://devdocs.prestashop-project.org/8/themes/getting-started/asset-management/#registering-in-themes
This is more a "nice to have" priority.
No mix of installed and generated files
Webpack writes the results to assets
but we want to put static assets that are not processed by webpack as well. This gives a mix of files with different "ownership" within assets
. It could be helpful to write all webpack stuff to assets/webpack/....
to separate things more clearly. OTOH, I try on our side with assets/custom
or assets/static
for the additional stuff we put there.
Just added this requirement:
error if installed modules don't match with the theme
If webpack needs to be run separately, there should be an error when the compiled assets are not fitting with the installed modules.
Hi @cruftex,
I will try to document it as much as possible in new doc page for version 4.0.0. We shouldn't throw any error thb. Every module can be optional to install beside core ones. There will be more optional modules and everything should be documented properly but I can't guarantee that nobody will face the same problem due not reading the documentation.