Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "npm run build"
-
You know what?
Young cocky React devs can suck my old fuckin LAMP and Objective-C balls.
Got a new freelance job and got brought in to triage a React Native iOS/Android app. Lead dev's first comment to me is: "Bro, have you ever used React Native".
To which I had to reply to save my honor publicly, "No, but I have like 8 years with Objective-C and 3 years with Swift, and 3 years with Node, so I maybe I'll still be able help. Sometimes it just helps to have a fresh set of eyes."
"Well, nobody but me can work on this code."
And that, as it turned out was almost true.
After going back and forth with our PM and this dev I finally get his code base.
"Just run "npm install" he says".
Like no fuckin shit junior... lets see if that will actually work.
Node 14... nope whole project dies.
Node 12 LTS... nope whole project dies.
Install all of react native globally because fuck it, try again... still dies.
Node 10 LTS... project installs but still won't run or build complaining about some conflict with React Native libraries and Cocoa pods.
Go back to my PM... "Um, this project won't work on any version of Node newer than about 5 years old... and even if it did it still won't build, and even if it would build it still runs like shit. And even if we fix all of that Apple might still tell us to fuck off because it's React Native.
Spend like a week in npm and node hell just trying to fucking hand install enough dependencies to unfuck this turds project.
All the while the original dev is still trying TO FIX HIS OWN FUCKING CODE while also being a cocky ass the entire time. Now, I can appreciate a cocky dev... I was horrendously cocky in my younger days and have only gotten marginally better with age. But if you're gonna be cocky, you also have to be good at it. And this guy was not.
Lo, we're not done. OG Dev comes down with "Corona Virus"... I put this in quotes because the dude ends up drawing out his "virus" for over 4 months before finally putting us in touch with "another dev team he sometimes uses".
Next, me and my PM get on a MS Teams call with this Indian house. No problems there, I've worked with the Indians before... but... these are guys are not good. They're talking about how they've already built the iOS build... but then I ask them what they did to sort out the ReactNative/Cocoa Pods conflict and they have no idea what I'm talking about.
Why?
Well, one of these suckers sends a link to some repo and I find out why. When he sends the link it exposes his email...
This Indian dude's emails was our-devs-name@gmail.com...
We'd been played.
Company sued the shit out of the OG dev and the Indian company he was selling off his work to.
I rewrote the app in Swift.
So, lets review... the React dev fucked up his own project so bad even he couldn't fix it... had to get a team of Indians to help who also couldn't fix it... was still a dickhead to me when I couldn't fix it... and in the end it was all so broken we had to just do a rewrite.
None of you get npm. None of you get React. None of you get that doing the web the way Mark Zucherberg does it just makes you a choad locked into that ecosystem. None of you can fix your own damn projects when one of the 6,000 dependency developers pushes breaking changes. None of you ever even bother with "npm audit fix" because if security was a concern you'd be using a server side language for fucking server side programming like a grown up.
So, next time a senior dev with 20 years exp. gets brought in to help triage a project that you yourself fucked up... Remember that the new thing you know and think makes you cool? It's not new and it's not cool. It's just JavaScript on the server so you script kiddies never have to learn anything but JavaScript... which makes you inarguably worse programmers.
And, MF, I was literally writing javascript while you were sucking your mommas titties so just chill... this shit ain't new and I've got a dozen of my own Node daemons running right now... difference is?
Mine are still working.34 -
Hmm our bundle js is already 1.35Mb maybe I should do something with that.
... Insert 2 hours of frantic webpack magic + babel-preset tweeking, tree-shake code optimization ...
- npm run build
- bundle.js => 1.37Mb
Great Success! I'm going to take a lunch...4 -
I'm investigating PRs for a super legacy codebase. Someone else already approved the PRs -- somebody who has never even run the code or had the project set up before.
The codebase hasn't been touched in two years, and it hasn't been updated in four. It's using CoffeeScript, Node v0, Electron v0.30, and Angular 1.x. I obviously don't have a dev environment anymore, either, and my previous dev env was on Windows, so I'll have to translate my custom build utilities from batch to bash (or much more likely: node).
To make matters worse: the PRs break both the initial project setup and the project itself (NPM can no longer find some installed packages, among other problems). And. someone already merged them into master. So: fuck.
I'm going to yell at the author and tell him to fix his shit. Why? Because when I check out my last commit prior to his PRs, everything works perfectly. Surprise!
I was so done with this project two and a half years ago. I'm still so done with it. I just don't want to maintain this anymore, or honestly even look at it. I would happily rebuild the project from scratch, but updating it from the days of IE8? No way.9 -
Angular is still a pile of steaming donkey shit in 2023 and whoever thinks the opposite is either a damn js hipster (you know, those types that put js in everything they do and that run like a fly on a lot of turds form one js framework to the next saying "hey you tried this cool framework, this will solve everything" everytime), or you don't understand anything about software developement.
I am a 14 year developer so don't even try to tell me you don't understand this so you complain.
I build every fucking thing imaginable. from firmware interfaces for high level languaces from C++, to RFID low level reading code, to full blown business level web apps (yes, unluckily even with js, and yes, even with Angular up to Angular15, Vue, React etc etc), barcode scanning and windows ce embedded systems, every flavour of sql and documental db, vectorial db code, tech assistance and help desk on every OS, every kind of .NET/C# flavour (Xamarin, CE, WPF, Net framework, net core, .NET 5-8 etc etc) and many more
Everytime, since I've put my hands on angularJs, up from angular 2, angular 8, and now angular 15 (the only 3 version I've touched) I'm always baffled on how bad and stupid that dumpster fire shit excuse of a framework is.
They added observables everywhere to look cool and it's not necessary.
They care about making it look "hey we use observables, we are coo, up to date and reactive!!11!!1!" and they can't even fix their shit with the change detection mechanism, a notorious shitty patchwork of bugs since earlier angular version.
They literally built a whole ecosystem of shitty hacks around it to make it work and it's 100x times complex than anything else comparable around. except maybe for vanilla js (fucking js).
I don't event want todig in in the shit pool that is their whole ecosystem of tooling (webpack, npm, ng-something, angular.json, package.json), they are just too ridiculous to even be mentioned.
Countless time I dwelled the humongous mazes of those unstable, unrealiable shitty files/tools that give more troubles than those that solve.
I am here again, building the nth business critical web portal in angular 16 (latest sack of purtrid shit they put out) and like Pink Floyd says "What we found, same old fears".
Nothing changed, it's the same unintelligible product of the mind of a total dumbass.
Fuck off js, I will not find peace until Brendan Eich dies of some agonizing illness or by my hands
I don't write many rants but this, I've been keeping it inside my chest for too long.
I fucking hate js and I want to open the head of js creator like the doom marine on berserk19 -
Used a starter to scaffold a new project. Have never used that starter before but it has more than 1400 starts on Github.
Two days after.... so far so good. The created project structure used some tools I haven't used before, some are good, others are not so good, but anyway I am towards the first release of my codes. I have done countless 'npm run build', 'npm run test', 'npm run fix', etc., but.... my fault, I haven't committed once since starting the project, thinking I would commit when the next function is implemented, next test case passed.... after all, what could go wrong anyway?
Finally, one last test case passed, I think I will commit and run 'npm publish'.... but wait, had a glimpse of the scripts section in package.json, there's a command named 'all'. An voice came out of nowhere was talking to my subconscious mind, "all.... build, lint, prettier, test..... yeah you should run all... it's another build script, the worst you can get is just some harmless error messages.....", and my fingers typed 'npm run all'...
Time stopped for a few seconds, file structure in project explorer was shifting, files & folders were disappearing & appearing, what's happening... and I looked at the 'all' script closely for the first time....
WHAT THE HELL, WHO SHOULD PUT 'git reset --hard' IN A BUILD SCRIPT WITHOUT ANY PROMPT????!!!!!!!
MY PLAN WAS TO COMMIT AND GO TO SLEEP, IT'S 1AM NOW!!! WHERE CAN I RECOVER THE LOST FILES????4 -
I just need to get this out.
NPM is not the worst dependency manager. It is way beyond any word in any language that can describe the most negative thing about it.
I developed nodejs projects. I like JS, it's a great language to work with. But not NODEJS, not NPM.
I can run my app in a F* browser but not once, not a single time that nodejs and npm can run at the first time. I spend way more time to build a working environment with nodejs and npm than to build my own app.
whoever developed these two pieces of crap had brains that filled with mud. And who gave them the courage to even put it out for people to use? JS is such a good language and they have ruined it.
There are so many dependency managers out there couldn't they just take a look at how human beings do things? I mean they have never seen APT or Composer or something else that actually work?
Or they just had so much ego that they had to let other people to feel how difficult their lives are.
I don't care about how you manage the dependency and I shouldn't. You people made these crap with one purpose that chould help others to develop easily but NOOOOOO, we have to spice it up, right? You just have to make it fat and greasy, right? You just have to make it doesn't work. I bet you people just redefined the F* CONSTANT of "How to Develope a System that Doesn't Work".
I don't know if NPM genius have ever did a information collection of their system. I bet most function that has been invoked is "throw error".
The funny thing is on NPM website, they provide Enterprise Solutions.... I would sue them for fraud.13 -
Just gonna leave this here because I am too lazy to write a proper article for my website:
If anyone is trying to create a Vue.js website with Node.js backend do NOT use express-vue, it is unnecessarily complicated and broken. Instead use this method I found.
You will need:
- IntelliJ IDEA / WebStorm / other IDE supporting multiple modules per project and tasks
- Nodejs and npm
- vue-cli
Step by step:
1. Create new empty project
2. Add your frontend module using vue-cli generator
3. Add your backend module using Express generator
4. Run npm build in your frontend module once
5. Move or remove public folder in your backend module
6. Create a symlink from your backend module root called public pointing to dist folder in your frontend module root
7. Make sure to add "Run npm build" from frontend module to your "bin/www" task (default task for Express module)
8. Enjoy developing your REST API in Node/Express and your frontend in Vue.js with single-file components and it being served by the same server that is providing the backend.
(Since they are separate modules and you are not mixing webpack and Node/Express you can add ts-loader, stylus-loader, pug-loader or any other loaders without screwing anything up)
For deployment you just need to copy the contents of dist into public on the server. (and not upload the symlink)6 -
So, I've had a personal project going for a couple of years now. It's one of those "I think this could be the billion-dollar idea" things. But I suffer from the typical "it's not PERFECT, so let's start again!" mentality, and the "hmm, I'm not sure I like that technology choice, so let's start again!" mentality.
Or, at least, I DID until 3-4 months ago.
I made the decision that I was going to charge ahead with it even if I started having second thoughts along the way. But, at the same time, I made the decision that I was going to rely on as little external technology as possible. Simplicity was going to be the key guiding light and if I couldn't truly justify bringing a given technology into the mix, it'd stay out.
That means that when I built the front end, I would go with plain HTML/CSS/JS... you know, just like I did 20+ years ago... and when I built the back end, I'd minimize the libraries I used as much as possible (though I allowed myself a bit more flexibility on the back end because that seems to be where there's less issues generally). Similarly, any choice I made I wanted to have little to no additional tooling required.
So, given this is a webapp with a Node back-end, I had some decisions to make.
On the back end, I decided to go with Express. Previously, I had written all the server code myself from "first principles", so I effectively built my own version of Express in other words. And you know what? It worked fine! It wasn't particularly hard, the code wasn't especially bad, and it worked. So, I considered re-using that code from the previous iteration, but I ultimately decided that Express brings enough value - more specifically all the middleware available for it - to justify going with it. I also stuck with NeDB for my data storage needs since that was aces all along (though I did switch to nedb-promises instead of writing my own async/await wrapper around it as I had previously done).
What I DIDN'T do though is go with TypeScript. In previous versions, I had. And, hey, it worked fine. TS of course brings some value, but having to have a compile step in it goes against my "as little additional tooling as possible" mantra, and the value it brings I find to be dubious when there's just one developer. As it stands, my "tooling" amounts to a few very simple JS scripts run with NPM. It's very simple, and that was my big goal: simplicity.
On the front end, I of course had to choose a framework first. React is fine, Angular is horrid, Vue, Svelte, others are okay. But I didn't want to bother with any of that because I dislike the level of abstraction they bring. But I also didn't want to be building my own widget library. I've done that before and it takes a lot of time and effort to do it well. So, after looking at many different options, I settled on Webix. I'm a fan of that library because it has a JS-centric approach. There's no JSX-like intermediate format, no build step involved, it's just straight, simple JS, and it's powerful and looks pretty good. Perfect for my needs. For one specific capability I did allow myself to bring in AnimeJS and ThreeJS. That's it though, no other dependencies (well, at first, I was using Axios because it was comfortable, but I've since migrated to plain old fetch). And no Webpack, no bundling at all, in fact. I dynamically load resources, which effectively is code-splitting, and I have some NPM scripts to do minification for a production build, but otherwise the code that runs in the browser is what I actually wrote, unlike using a framework.
So, what's the point of this whole rant?
The point is that I've made more progress in these last few months than I did the previous several years, and the experience has been SO much better!
All the tools and dependencies we tend to use these days, by and large, I think get in the way. Oh, to be sure, they have their own benefits, I'm not denying that... but I'm not at all convinced those benefits outweighs the time lost configuring this tool or that, fixing breakages caused by dependency updates, dealing with obtuse errors spit out by code I didn't write, going from the code in the browser to the actual source code to get anywhere when debugging, parsing crappy documentation, and just generally having the project be so much more complex and difficult to reason about. It's cognitive overload.
I've been doing this professionaly for a LONG time, I've seen so many fads come and go. The one thing I think we've lost along the way is the idea that simplicity leads to the best outcomes, and simplicity doesn't automatically mean you write less code, doesn't mean you cede responsibility for various things to third parties. Those things aren't automatically bad, but they CAN be, and I think more than we realize. We get wrapped up in "what everyone else is doing", we don't stop to question the "best practices", we just blindly follow.
I'm done with that, and my project is better for it! -
Vodafone India is so shit omfg
Run npm install, ERROR json parse error due to ssl exception
Run pip install, again ssl exception
Run gradle build, again ssl exception!!!
Now everytime i gotta make a new project or install a dependency in anything, i have to pray to the blood god that cache contains a valid/uncorrupted package dependency or else ill have to nuke cache and borrow internet from someone else.
Once i port it to some other operator, i am gonna incinerate this mf sim.12 -
I want a tool called "bogo-npm" which creates a VM and then installs random versions of npm and dependencies in a cycle until the build is successful. It'll probably be the biggest optimization that dogshit ecosystem has ever seen.
I'd just let it run over night and save myself the urges to strangle every single fucking developer who added dozens of dependencies to a stupid near-static website.
And the creator of the abomination called `npm uninstall` which for some fucking reason does the same as `npm install` and then obviously fails because that's the reason I wanted to remove that package in the first place.
We need more heroes like that leftpad dude.3 -
If you could choose one, what should happen in 2020 :
1. Apple let developer build iOS apps on non Apple machines
2. NPM/Maven/... run 10x faster
3. Javascript dies and gets replaced by a better language
4. Governments stop trying to ruin encryption
5. Facebook splits
6. Quantum computers are being sold for consumer use
7. We have our first high - level generic AI working17 -
How greedy can you get?
> boss takes half assed gdpr project : branch xyz
> branch xyz requires deprecated version of npm/node
> I re-install node this time with deprecated version
> Wow this node is configured with ant build
> ECMA 5, config but code is shit as fuck
> still I get the job done , cannot test it because code is shit as fuck and I will never any thing to fix that un healthy code
> code doesn't run on client side,
> no shit Sherlock
> get a call from boss, it urget look in it and fix it -
If you write a blog post on how to build “some-component” and the first step in your article is to run “npm install framework-some-component”…
I hope you die in a fire. -
could'nt build my react app, didn't understand the error Module not found: Error: Can't resolve '.... app.css'
worked on my macbook, didn't on my ubuntu server, took me 3 days until I realised the css file is named App.css and not app.css
wtf apple, wtf me -
Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.3 -
How to run PHP in a container :
1. Begin a docker file for an existing php cron app (when all you know is php, everything looks like a php app)
2. Set the FROM.. Apt get update .. Do composer install
3. Builds the image
4. Discover I need git
5. Add git to apt get install step
6. Builds the image
7. Launch the php script
8. Fatal : use of undefined constant SOL_UDP
9. Opens the source code of the third party. The there's no mention of where that constant is from.
10. Spend many minutes online to find what's missing.
11. Find the PHP sockets page about that option. Digs into the documentation to find out that's missing from the installed PHP.
12. Find out I need to add a step to install the socket extension in my docker file.
13. Build the image again
14. Execute it, finally it works
15. Remember why I hate php
(for brevity I've omitted the even more complex part of having to set up zlib)
How to install node js in a container image:
FROM node:8
ADD package.json
RUN npm install7 -
So, i'm trying to get linkr (a pretty cool short link service) to work in a docker container since 4 hours now to host it on my server. There is no official container because it needs a working database connection and stuff during installation which can only be done via console and (for whatever reason I couldn't find out yet) need to be done while building the container. The problem is, I can't connect it to the database while building the container so there is no database during installation to create tables and stuff and the build will fail. ARGH.
Why the hell would you do this????? Theyre actually saying in their readme there is no dockerfile because the config options are specific to your configuration...?!?!
The thing is entirely written in python, so reading and parsing configfiles on the fly should not really be a problem.
Of course I could ssh into the container and run the installation script but that's not the point.
Docker is not about being lazy.
It's about portability.
Maybe I don't want to bloat my server with your 39579372639 npm dependencies? Or I don't want to install a freakin apache, because I have every other site on nginx and therefore wouldn't work with apache.
AAAAAAAARRRRRRGGHHGGGGG
in the end, I'm probably going to modify the thing to install tables when running the container and giving the first user admin rights instead of prompting to enter credentials for a new admin user.
And yet I didn't even speak python. -
I was trying to build this AWESOME react native application.
1. install npm and react native [3 min]
- oh wait install yarn [about 10 min]
- how about expo 1 min
- and install expo on my phone [ 1min]
2. create a react native app
umm install pod [10 min]
run npm ... figure failures and stuff [20 min]
it's been almost 1 hour now and I forgot what I was building.2 -
So I have replaced npm with yarn due to performance boost and the lockfile.
Never will there be problems with unexpected versions of dependencies!
Wait.
Why is my build writing a yarn.lock?
It turns out, if you want yarn to exit with an error code if it's out of sync with the package.json, you have to run it with:
$ yarn install --frozen-lockfile
Only then it will produce an error.
The default for it is to notice, oh, there is some new dependencies, let resolve this to the most current version I can fetch, and use that one, and write a new lockfile. Meaning you will get unknown futures of a depdency. O_o
That's totally going besides the purpose of having a lockfile in the first place. Why would anyone want this?
Action I do expect to touch the lockfile:
add / remove / upgrade
Action I do NOT expect to touch the lockfile:
install
Install should just install whatever is in there, and if it realizes it is out of sync, die with an error.
But that would make sense!
Who needs sensible defaults anyway!?5 -
me to myself:
stick with one already
sometimes it's npm run build, npm run prod, npm run production, npm run dev, npm run watch, npm run serve, npm run hot, npm run start.
:D5 -
So as part of my news years resolution, I thought id build an app and I thought I would build it in vue.js and native script with a shared codebase, I've started with a fresh project and already I have an error, one that I've not caused, this is in router.js. see if you can spot it.
module.exports = (api, options) => {
require('@vue/cli-plugin-router/generator')(api, {
historyMode: options.routerHistoryMode
};
export default new Router(options);
}
When I've fixed the syntax error, I then get, the error:
/src/router.js: 'import' and 'export' may only appear at the top level (5:0)
This is when I run "npm run serve:ios"
if anyone has encountered this, please let me know how you fixed this.2 -
Are you kidding me? windows-build-tools developers does not know that devs like me would run npm update -g from a standard user account? Don't tell me that they use system administrator accounts for their day to day dev and qa tasks1