Hi,
I find myself struggling with build tools more than I would care for.
This usually happens with projects that are a year old or older.
Modules break or become deprecated, causing the whole project to break down and prevent me and other people from working on it until we find the problem.
I'm sure everyone knows this problem and has dealt with this before.
If we are lucky we can just upgrade the whole thing to the latest Webpack version and everything will work again.
Sometimes just removing the node_modules and run "npm install" does the trick.
Other times nothing seems to help, especially when there are both Mac and Windows users working on the project and using the same build tools.
Even in projects where I know the tools worked several months ago, something can go wrong and I have to spend hours searching for a solution.
What are your thoughts on the build tools we generally use for web development?
Do you think everything would be easier if we went back if we stopped using them at all?
Top comments (9)
I think it depends on the context, but yes. I've made some sites for friends and family, where I don't work on them for a while, but every now and then I have to dip in and make a small change they want, and after experiencing this problem, I've abandoned build tools for these projects. Plain old HTML, JavaScript and CSS in the browser.
Sure it means I can't do certain complicated logic as easily, but it's never actually needed for these kinds of projects. Maintenance is key.
I think if I were an agency or a shop I could probably find another form of consistency of process which does use build tools, but as I am not that, vanilla all the way.
It doesn't sound like they're talking about one-off family-built websites, but an organization that needs CI/CD to reliably build and deploy their work. One crucial thing they're missing, though, is pinning their dependencies and dev/prod environment repros.
It may be worth investing in containers which will complicate orchestration of deployments, but will make everything consistent.
I ended up using shell scripts to manage native commands. Like using scss -w for scss and same for typescript, PHPCS checks etc, Instead of using build tools like gulp or webpack or parcel.
But on some simple projects, I just use npm exec to execute scripts.
This works if you are the only one working on the project.
I can image you would need to create a detailed readme explaining every command and which libs to install when you are working in a team.
But of course, one could also say the same about a webpack/npm setup, even if it only has one command.
Not really... These are personal shell scripts which acts as wrapper for tooling. I mainly freelance with PHP or node in backend, and Typescript and Sass for frontend.
So for example new-project.sh will interactively ask my project parameters and then
I do have predefined template for webpack, and wordpress, basic slim-starter, express, meteor, vue-laravel, etc.
As for the details of readme, It is just 'npm run build' 'npm run build-prod' 'npm run clean' etc. All commands are listed in npm script block.
This is pretty damning - can I ask if it's Node JS that you're using?
I'm using npm and webpack to compile and bundle javascript while also minifying and auto prefixing sass.
That and browser sync to make our lives a little easier while doing html/css.
Nothing too complicated to be honest.
Most of the time when I'm the one having problems I can fix it pretty quick.
The real misery begins when a Windows user is getting weird output from npm for whatever reason.
The last problem was when someone encountered this error.
(Couldn't open browser (if you are using BrowserSync in a headless environment, you might want to set the open option to false))
I do not have the issue on my mac while it completely breaks everything for the other developer.
Googling the issue did not make me any wiser.
For some reason it's also the person that really does not like build tools with the biggest and weirdest issues.
I never used Webpack, I prefer Gulp because it just run tasks and listen to me when I want to do X when Y. I do not like all the magic and I prefer to know which tool do what when, so Gulp is my go to.
I happened to maintain old projects that I did some months ago, and going from Gulp 3 to 4 was a breeze.
I think in the end if you try to go progressive, and test everything like a psycopath even if you just add this tiny little package you might be able to locate the source of the issue earlier, but I generally have the feeling like you that build tools have made our lives more complicated (mostly if you are not a full front-end developer that does other things like keeping up with all those build tools releases and features).
I'm actually also refactoring our old Gulp projects to Webpack because they have become completely outdated and only throw errors.
Instead of debugging the whole thing I just update it to the latest and greatest.
The biggest cause is updating the node and npm versions on my machine of course.
So in a way it's my own fault.
Maybe this is why agencies often have their own virtual machine where they control versioning for all developers instead of lettings the developers update it whenever they want.