You can use kamal-proxy, recently released. It handles SSL and zero downtime deployments. It’s small and from what I checked the code is easy to read and understand.
I agree with this. But dont just use `npm ci`on prod builds since that would typically include all the dev dependencies as well in your production builds, which is not usually desirable. It might be possible to add the `--only=production` flag to npm ci? But otherwise, as pointed out, pinned versions are needed for all dependencies.
Last time I know during node 16, npm install updates your package-lock.json, but for patch version number (unsure about minor version) only and if the package.json is using relative version number. Definitely use npm ci or yarn if you want to adhere to lock files.
> if the package.json is using relative version number
What do you mean by this? You can specify dependency versions using "^" which means "I accept new minor and patch versions" or "~" which says "I accept new patch versions", or a bare version to say I want an exact version; but none of those have anything to do with a bare "npm install" command. They are relevant when you install a new package, with "npm install <package>". That is a totally different operation, and it absolutely can update versions when needed.
However, when you just do "npm install" it does not update your package-lock.json to the latest version that matches your semver requirements in package.json. That will only happen if you install a new package that needs it or you use `npm update` or some other command.
This is easy to test but it's also intuitively correct- you don't expect to run `npm install` and have an uncommitted change to `package-lock.json` appear, and that does not happen in normal usage.
It is kind of unfortunate that "npm install" and "npm install <package>" use the same verb of "install" for two different things- other package managers don't make this mistake and it avoids the sort of misconception we're running into here.
Exactly what I said, I have experience with ~ but not with ^ and have never used it. Let's say that you have a package version ~1.2.11 and have 1.2.11 as installed version in package lock. Then if let's say 1.2.13 is out there, npm install will update package lock to that one. npm ci won't change that. package.json file will kept unchanged though.
No, "npm install" doesn't actually do that. In the situation you are talking about, "npm install" and "npm ci" behave the same.
It makes sense that they behave the same here right? What is the point of a package lock if just installing packages on a new copy of a codebase updates the dependencies?
Package locks aren't just about deploying: As a developer, I need to be assured that the code I'm running is the same as my coworker.
Yes I think you are right when NPM first introduced it, which was in NPM 5 [1]. At that time package locks were new.
Node 16 shipped with NPM 8, and by then this was not the behavior any more. I don't remember exactly when, but I believe it might've been in NPM 7 when this changed. Node 15 would have been the first release to ship with at least NPM 7 [2]
Honestly no guarantees it worked as intended right at that release, but the intention is clear.
EDIT 4: I realize that the following may present retort but it matches my mental model perfectly:
> If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above.
This is what I've mentioned elsewhere: You should not update package.json's versions and deploy it and expect that versions won't change when NPM install runs. In fact, npm ci will just fail in this situation, which is a Good Thing (TM), and is documented as such.
LAST EDIT SRSLY:
It is conceivable, especially given OPs other red flags, that perhaps they were on an older Node/NPM like Node 14.
That's another practice that I regularly do, pin NPM itself in deploy scripts. While I was using Node 14, I was using NPM 8, because you can just "npm i npm@8 -g" to upgrade your NPM regardless of Node version.
Not all. One mentioned in the article, Qwik, uses a different technique the authors call resumability. It’s similar in that it applies JS to components client side which were rendered with the same code server side. The subtle differences:
- it derives its initial client state from the HTML, rather than re-running the initialization which already ran on the server
- it doesn’t render top down, it resumes interactive components on demand (on first user interaction by default)
- it doesn’t load any of that code at all by default; if your page is fully static, none of the code ever gets loaded
This is similar to frameworks like Astro which use a technique called “partial hydration”, but with Qwik it’s handled by the compiler. Another which is somewhere in between (and has been doing all this for years; I’m not sure exactly where its most recent release sits on the spectrum) is Marko.
Pretty on topic considering I built this because of the device lol.
I love it, with the latest update extremely low latency pen, excellent battery life, helped me finally to start being disciplined about notes (couldn't do it with just notebooks), pretty. I also like to draw so it scratches that itch. IMHO the downsides (other than no web browser) are pretty much the regular eink stuff - no backlight, fairly slow UI, some artifacts until you refresh the screen etc... But I like it, imho it's worth the money, and the Supernote team is excellent and responsive to user feedback, which is what I want my money to support in the day and age of closed vaults of idiotic products.
It's the smallest (usable) full frame camera from Sony (there's another smallrer one from Sigms but it doesn't have a viewfinder). Its weight is 509g / 1.1 lb, has the same sensor as the Sony Alpha 7III and better autofocus (tracks humans as well as animals with eye detection - for photo and video).
