These are developed for NodeJS, and there simply isn’t a PHP-based tool that can process them.The sass package on npm is a pure-JavaScript package built from the Dart Sass implementation. If you use postcss or a postcss plugin, you won’t be able to use these in a PHP-only environment. I can’t think of anything I cannot do with PHP that I have been doing with NodeJS. Extending it with very specific, Symfony-style console commands makes it even more powerful. This approach is fun to work with and actually really really fast. With these 6 lines of YAML instructions, all of the compression previously done with NodeJS is no longer needed and I can focus on more important things. public depth: 4 extensions: '.txt.md' tools: 'brotli,gzip' github/workflows/deploy.yml - uses: with: path.
But hey, Github Actions are really convenient. I don’t need these files in my repo nor on my local machine, so instead I outsourced this task to a Github Action – which somewhat violates my lean deploy policy. Now that my build is done with PHP, I could easily compress files with PHP. In that article I used a Grunt task to create these files. Read about this in my article “Pre-compress static assets with Brotli and Gzip” to learn more about the details. Their only purpose is to reduce server and CPU load and to speed up the server response of my site. br versions of my assets, that shall only exist on the production server. But there are other assets, like pre-compressed. Most frontend assets that I use, need to be built locally, so I see CSS & JS in the browser during development. And more importantly, there’s less risk of errors that might keep you from deploying. The less tasks you need to run during deploy, the faster deploys will be. When talking about building frontend assets, there’s another topic lurking around the corner: deploys.ĭeploy processes, ought to be as lean and compact as possible.
Less switching between programming languages (Javascript and PHP) makes my development easier.Dependencies are now in one central place, the vendor folder and not distributed accross node_modules and vendor.I have less clutter, since my project doesn’t need a package.json, no package-lock.json, no Gruntfile, no node_modules folder and no additional entries to my.Will a single uglify-es node package still work in a year or two? Or will it be abandoned and needs replacement? Things that that work with PHP today will most likely work in 2-3 years from now, as well.
I have less dependencies to worry about.I work on a PHP project, so using PHP is my first choice. I chose PHP anyways, and I have to say I’m happy with the result: Besides, they can do so much more, things frontend developers use nowadays. They are specifically made for tasks like: compile assets, copy fonts, join and minify scripts. Obviously, these tools are well established and stable. Why choose PHP over NodeJS, webpack, grunt or gulp? Now you can build your CSS like this: vendor/bin/pscss -style=extended templates/main.scss public/assets/css/main.css vendor/bin/pscss -style=compressed templates/main.scss public/assets/css/Īnd if you want a shortcut for this, that’s intuitive, you can add a composer script, doing exactly that. Add it to your project with composer require scssphp/scssphp. I found scssphp, a PHP-based SASS compiler. In this article I want to outline how I realised frontend asset builds without the use of NodeJS and NPM.
0 kommentar(er)
