How ICMS 2.0 should manage front-end assets?

[MekDrop]

We have composer for all PHP libraries, but what about front-end libraries like jquery? What we should use?

From what I know, we have right now two main options with few suboptions:

1. Use composer for that:
   a) fxp/composer-asset-plugin - most popular variant, however it needs to be installed globally on the server
   b) beelab/bowerphp - doesn't need global install, but doesn't work with all assets and also only bower, which looses popularity
   c) foxy/foxy - acts more like proxy between composer and npm
2. Use native like many standalone networks does. I think this is most elegant way however I'm not sure how to make possibility to add it easy into modules. And another problem - not every shared hosting has preinstalled such tool.

[fiammybe]

Initially I was thinking about the fxp/composer-asset-plugin but I am not sure anymore that that is the best option. There are also packages in composer itself for most of the high-profile javascript libraries, but they aren’t well integrated if you include them that way. A good question to which I don’t really have an answer. Any idea how other CMSes do this? Van: Raimondas Rimkevičius Verzonden: maandag 29 januari 2018 13:36 Aan: ImpressCMS/impresscms CC: Subscribed Onderwerp: [ImpressCMS/impresscms] How ICMS 2.0 should manage front-end assets?(#134) We have composer for all PHP libraries, but what about front-end libraries like jquery? What we should use? From what I know, we have right now two main options with few suboptions: 1. Use composer for that: a) fxp/composer-asset-plugin - most popular variant, however it needs to be installed globally on the server b) beelab/bowerphp - doesn't need global install, but doesn't work with all assets and also only bower, which looses popularity c) foxy/foxy - acts more like proxy between composer and npm 2. Use native like many standalone networks does. I think this is most elegant way however I'm not sure how to make possibility to add it easy into modules. And another problem - not every shared hosting has preinstalled such tool. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[MekDrop]

My short research: all popular cms'es just puts assets into folder and that's it. No specitific assets handling. But I'm not sure if this is a good way.

3. I think it would be possible to offer 3rd option. We could use standard npm tools and for all users that doesn't have npm or yarn installed on server we could provide cloud based service (we download, build all assets on our server and than upload result to users server with some kind of rest api).

For building operations we would need server with shell access. I'm not sure if we such have right now. If no, I don't think so that will cost much but if I'm wrong (that means that such service would be on big demand) we could maybe start offer paid services for everyone who doesn't like to wait much more.

[fiammybe]

I more or less came to the same conclusion. Most CMSes have conventions where to store the libraries, but that library pool isn’t really managed. When it is managed, you can have cases where the managed version of a library is out of date, but no new managed version of a library is available (Drupal with the jQuery component in D7 for example). I think we’ll leave the non-PHP libraries as-is, detailing what folder they should be, but not restricting that more. At least not in the first couple of versions of Icms 2.x I find your idea for the service intriguing, but I think that the complexity of all the different libraries that are handled all differently, coul be overwhelming.

[MekDrop]

Most JS libraries could be resolved with WebPack. Also, it lets include different assets versions in same website without conflicts. Laravel Mix is easy way to walk into WebPack world. So, maybe we could move our JS core libs to webpack with some legacy bindings and for module authors just ask them to use webpack for prebuild their assets and then load their builds (they will need to include prebuilded JS files in their views)? Later we could implement a bit better way for doing such things.

[fiammybe]

I kinda like the idea of working with webpack. Let’s investigate some options there and see if we can get a first working solution in the next few days.

[MekDrop]

I think we should postphone this one question. I know how to implement this but this needs some free time. Maybe at the first we need move as much from core to composer libs as we can - later it would be easier to make some improvements to core

[MekDrop]

I think easiest solution for us at least for now would be to use kriswallsmith/assetic. It's impossible with it download assets but it's possible to include front-end assets and compile, minify if is needed from any path. So, I think it would be good enough for us for a while.

[MekDrop]

It seems DYFeng/composer-asset-plugin that tries to fix many issues that fxp/composer-asset-plugin has, so probably this could be a good tool for us to download module and main front-end assets.

[MekDrop]

DYFeng/composer-asset-plugin seems doesn't work yet.

Xoops has assets manager. It works. But it is not usable outside their CMS. It has good ideas but not so good implementation. So, that's why I think best way it would be a create composer lib and include it in our CMS.

How I think this lib should work:

• automatically optimize images in public assets folder
• minimize javascript and css files in public folders
• automatically compile less, scss, coffeescript, dart, handlebars, react jsx, stylus, typescript, gss files automatically
• when compiling assets add prefix by module
• provides methods:
  • to get url to asset by filename
  • to set/get assets public dir
  • to update assets for module (it would be invoked when module is installed or updated)
  • to delete assets for module (it should be deleted when module is uninstalled)

[MekDrop]

Based on ziadoz/awesome-php#742 it seems that kriswallsmith/assetic probably will not be updated ever. So, it's not a good choice for us :/

[MekDrop]

nodejs-installer composer plugin that installs npm in vendor folder. So, NodeJS doesn't need to be installed on the server to be able to use it for assets.

One possible problem here - what to do if exec PHP command is disabled? In that case we have npm but we can't use it. Would be this a major problem for us?

[MekDrop]

asset-packagist.org is another way how we could include assets for modules/cms. It's a repository that lets download many popular front-end assets with composer without any plugins. Looks good, but problem with it is that we everything goes to vendor and with #159 vendor is no more a public folder. Another problem is that it doesn't provides ant tools how to work with ES modules and these things now use many front-end developers.

[MekDrop]

After some investigation I think I have figure out how assets management for ICMS should work. imponeer/composer-yarn-installer downloads and installs yarn if is not available on system. foxy/foxy fetches package.json from modules and updates local node modules installation. Than another not yet available composer plugin would find modules with encore.config.js. This plugin will merge all these JS files and starts Symfony Encore that builds JS modules. These modules will be able to be included on website. Of course if anyone would like to use old style script inclusion, they could use if they want. Probably > 90% old style scripts would work.

Too not run always composer install or composer update commands for updating assets two commands will be available:

• composer assets:update - one time assets compile
• composer assets:watch - stars runner that watch for assets changes and recompiles if something changes.

[fiammybe]

The issue I have here is that you need a web host that needs command-line access, and it makes things much more complicated.
I would be in favor of keeping our current way of handling the javascript assets for now, and not making this a requirement for 2.0.

In my view, the front-end developer has the responsibility to make the build, and then push the finalised product to the CMS. There are too many frontend build pipelines (Ruby, node.js, rust, bower, gulp, ...) around, and we shouldn't limit the options for frontend development (theming, javascript framework integration), because things change so fast in that domain, that it will be impossible to stay up to date.

[MekDrop]

Maybe pipelines are too much for us right now, but I would like at least add more secure assets instaltion model. Right now including in module folder as works now exposes also other files that shouldn't be accessible.

[github-actions]

This issue was automatically marked as stale