Be me, new dev on a team. Taking a look through source code to get up to speed.

Dev: **thinking to self** why is there no package lock.. let me bring this up to boss man

Dev: hey boss man, you’ve got no package lock, did we forget to commit it?

Manager: no I don’t like package locks.

Dev: ...why?

Manager: they fuck up computer. The project never ran with a package lock.

Dev: ..how will you make sure that every dev has the same packages while developing?

Manager: don’t worry, I’ve done this before, we haven’t had any issues.

**couple weeks goes by**

Dev: pushes code

Manager: hey your feature is not working on my machine

Dev: it’s working on mine, and the dev servers. Let’s take a look and see

**finds out he deletes his package lock every time he does npm install, so therefore he literally has the latest of like a 50 packages with no testing**

Dev: well you see you have some packages here that updates, and have broken some of the features.

Manager: >=|, fix it.

Dev: commit a working package lock so we’re all on the same.

Manager: just set the package version to whatever works.

Dev: okay

**more weeks go by**

Manager: why are we having so many issues between devs, why are things working on some computers and not others??? We can’t be having this it’s wasting time.

Dev: **takes a look at everyone’s packages** we all have different packages.

Manager: that’s it, no one can use Mac computers. You must use these windows computers, and you must install npm v6.0 and node v15.11. Everyone must have the same system and software install to guarantee we’re all on the same page

Dev: so can we also commit package lock so we’re all having the same packages as well?

Manager: No, package locks don’t work.

**few days go by**

Manager: GUYS WHY IS THE CODE DEPLOYING TO PRODUCTION NOT WORKING. IT WAS WORKING IN DEV

DEV: **looks at packages**, when the project was built on dev on 9/1 package x was on version 1.1, when it was approved and moved to prod on 9/3 package x was now on version 1.2 which was a change that broke our code.

Manager: CHANGE THE DEPLOYMENT SCRIPTS THEN. MAKE PROD RSYNC NODE_MODULES WITH DEV

Dev: okay

Manager: just trust me, I’ve been doing this for years

Who the fuck put this man in charge.

When I Install An NPM Package .........

1.Runned The Install...

2.Watched the Progress Bar For 2secs

3.Got Bored, Opened Chrome for some entertaining content ( ͡° ͜ʖ ͡°)

4.Rechecked the Install after 20mins still 15%

5.Did take a break, ate something

6.Rechecked still 27%

7.Watched a little while the progress bar until I saw the Fatality.

CMD Has Stopped Working...

Sorry if this sounds like retard question on linux system

I installed nvidia driver on my laptop (720M) and it showed black screen after reboot, BUT if I enter my password and hit enter the screen goes back to normal on desktop, it just didn’t show anything on the first lock screen

I’ve followed linux mint nvidia driver instructions, removing the package re installing, etc.

P.S. All of the question I found on the internet seems to be total black screen after installing the driver, whereas mine could work after I entered my password

Mgr: composer require. That's all you're allowed to do. I want you to manually go through our word press site, check which ones need an update. And do a composer require in the command line for each to update them.

Me: wouldn't it make more sense to just increment the version in the composer.json and then run update?

Mgr: no, you don't understand how composer works, it's very complicated. Just do require. Don't ever do update.

Me: *does it anyway (reverting later of course) and compares update vs require and their differences in the lock file*

I mean it looks like 'update' is updating important dependencies for each of the packages as well as the package itself... The 'require' just seems to download the package itself but no updates to dependencies for those packages.

But seriously is composer that complicated that I can't just do an 'update'?

I've been reading the composer documentation and it seems to be saying that update is the better way to go...

I'm doubting myself these days...

* package-lock.json * merge conflict

ME: fuck fuck fuck, C-s I-Search: HEAD
ME: this shit is much i can't handle it, fuck

ME: rm package-lock.json ; npm install

Discords update "policy" is really annoying.

I daily-drive Manjaro and discord refuses to allow you to log in with an older client version when they release an update.

Manjaro's stable takes about two weeks to catch up so when this happens I'm stuck looking for an alternative way to update.

Usually I go for the AUR or (if available) unstable branch package but today the AUR wasn't up-to-date yet when I encountered this problem.

This is a minor inconvenience and was fixed about an hour later when the AUR was updated with the newer discord-electron-bin but I just don't get discords game here?

Why not allow the previous client version to connect and alert users of an available update like any other sane chat application does?

You could go for a time period like two weeks or a month and AFTER that start forcing users to update. I don't get why they force it the instant they release the update.

Just wanted to share this annoyance here, maybe someone encounters this possibility when designing update cycles for their application. I urge you not to instantly lock-out older versions. It's annoying, useless and restrictive. Or if you do so, opensource it so repositories can immediately build from source and sync and don't need to wait for a maintainer to update the bin in the repo.

Finally made my node production server stable enough that I could focus on writing tests*. I start by setting up docker, mocking cognito, preparing the database and everything. Reading up on Node test suites and following a short tut to set up my first unit test. Didn't go smoothly, but it's local and there are no deadlines so who cares. 4 days later, first assert.equal(1+1, 2) passes and I'm happy.

I start writing all sorts of tests, installing everything required into "devDependancies," and getting the joy of having some tests pass on first try with all asserts set up, feels good!

I decide to make a small update to production, so I add a test, run and see it fail, implement the feature, re-run and, it passes!

I push the feature to develop, test it, and it works as intended. Merge that to master and subsequently to one of my ec2 production servers**, and lo and behold, production server is on a bootloop claiming it "Cannot find module `graphql`". But how? I didn't change any production dependencies, and my package lock json is committed so wth?

I google the issue, but can't find anything relevant. The only thing that I could guess was that some dependencies (including graphql) were referenced*** in both, prod and dev, and were omitted when installed on a prod NODE_ENV, but googling that specific issue yielded no results, and I would have thought npm would be clever enough to see that and would always install those dependencies (spoiler: it didn't for me).

With reduced production capacity (having one server down) I decided to npm uninstall all dev dependencies anyway and see what happens. Aaaaand it works.....

So now I have a working production server, but broken local tests, and I'm not sure why npm is behaving like this...

* Yes I see the irony.
** No staging because $$$, also this is a personal project.
*** I am not directly referencing the same thing twice, it's probably a subdependency somewhere.

npm has to be the single worst package manager on the planet... Trusting devs to use semantic versioning properly and forcing devs to trust authors of dependencies to use it properly is nothing short of insane. The package-lock that is "supposed to be version controlled" causes *constant* merge conflicts. Using shrinkwrap in its place is borderline useless because it Doesn't. Lock. High. Level. Dependencies.

I don't know who designed this, but I want to give them a very bad day for every hour I've spent trying to lock versions correctly on a live project.

Not to mention requiring root by default to install things that can just run whatever they want is ludicrous.

I just finally took time to look at creating symbolic links for node modules and package and package lock json files all from a boilerplate code for my frontend projects,

I saved over 15gb of disk space,

my SSD is 40gb so that's fair

now I have all my node modules for frontend projects in a separate container and node modules for backend projects in a separate container

I still havent figured out how to trim down my package.json file before pushing because there'll be some unused libraries.

for now any direct changes I make to the package and package lock json files will be reflected in the the symlinked directory and them reflect over all projects that share it

I have to be careful here

So after deploying an update for my apps api this morning, I very quickly had to move hosts as openahift for some reason does not install express on its 8.x container, heck its not even in the package lock file, and no help from Google. On the plus side, new ones faster, even though it's further away, and I can only image a replica set DB is better than a single instance.