Thank you. I don't need to "fix" a commit before it ends up on a remote branch. Sometimes I expect a commit to pass checks and sometimes I don't. Frankly, don't even run pre-push hooks. Just run the checks in CI when I push. You'd better be doing that anyway before I'm allowed to push to a production branch, so stop breaking my git workflows and save me the time of running duplicate checks locally.
Also, if most developers are using one editor, configure that editor to run format and auto-fix lint errors. That probably cleans up the majority of unexpected CI failures.
Pre-commit and pre-push hooks are something developers can voluntarily add (or enable) to shorten the latency until they get feedback: instead of the CI rejecting their PR, they can (optionally!) get a local message about it.
Otherwise, I agree, your project can not rely on any checks running on the dev machine with git.
Appreciate the perspective. I've worked on projects where hooks are auto-configured, and pre-commit is just never something that's going to agree with me.
I prefer to be able to push instantly and get feedback async, because by the time I've decided I'm done with a change, I've already run the tests for it. And like I said, my editor is applying formatting and lints, so those fail more rarely.
But, if your pre-push checks are fast (rather than ~minutes), I can see the utility! It sucks to get an async failure for feedback that can be delivered quickly.
> But, if your pre-push checks are fast (rather than ~minutes), I can see the utility! It sucks to get an async failure for feedback that can be delivered quickly.
I'm a fan of pre-commit/push hooks, but they have to be fast. At <dayjob> our suite of pre-commit hooks are <50ms and pre-push hooks are <5s. They get regularly reviewed for performance, and if anything can't be made faster, slow pre-commit hooks will get ejected to pre-push, and slow pre-push hooks will get ejected to the regular CI suite.
In our case same hook is re-ran on server side; the pre-commit hook is purely to increase velocity
... and cos most people using git will have to take a second if the hook returns to them "hey, your third commit is incorrect, you forgot ticket number"
I can only conclude that people in this thread are being intentionally obtuse.
This isn't a question of ideals; it's addressing the uptick in illegal actions by immigration officials during the current US administration. It's addressing the selective application of the law to further conservative agendas.
Yes, some immigration enforcement is legal. Congratulations.
> addressing the selective application of the law to further conservative agendas
Does selectively not enforcing immigration law further liberal agendas?
- House seats (and therefore electoral votes) are determined by census - which includes illegal immigrant populations.
- If you can waddle across the border at 8.5 months pregnant, you can birth a citizen with no further requirements.
Ergo, "sanctuary cities" and other intentional lack of enforcement allow states to pump up their representation in Congress and increase government handouts.
Sure, the House is almost evenly split, so a few seats here or there would have an impact. But the net result would probably be further mitigated by gerrymandering, other population shifts, and so on.
One other thing I appreciated from this article is how it touches on comments about simply following the law. Just because something is legal, does not make it morally questionable (at best). From the article:
> The apportionment of seats in Congress is required by the U.S. Constitution, which says that the census will be used to divide the House of Representatives “among the several States according to their respective numbers, counting the whole number of persons in each State,” except for enslaved people, who, until the late 1800s, were counted as three-fifths of a person, and certain American Indians.
> would suggest others consider what an evil leftist
What are some things that could they do?
Right-leaning policy in 2025 typically leans towards enforcing the laws as written: in this case, immigration law is being bolstered by surveillance technology.
Which laws are liberals going to theoretically now start radically enforcing that conservatives were turning a blind eye to? Flock cameras don't exactly help the IRS make the rich "pay their fair share."
Any political ideology could be bolstered with the heavy handed use of surveillance technology. That's why groups like the ACLU and EFF exist. They both vehemently agree that there's no such thing as a good police state. Even if your team is running it.
If you want specific examples, I'd point to the Freedom of Access to Clinic Entrances Act. The left wants to throw people in prison for years for protesting while the right wants to pretend it doesn't exist and allow women seeking abortions to be intimidated. I'd also point to the levels of technology deployed to catch the January 6 perpetrators. I live in DC and have a hard time doing a both-sides here since the experience of living in a city under attack is still rather raw; whatever your views, you can't describe the right's response as "enforcing the laws as written."
Not controlling transitive deps makes this vastly less useful because direct deps can specify version ranges (e.g. latest minor version). Personally I'd stick with pnpm's feature.
This is why one should pin all direct and transitive dependencies with their checksums and not upgrade everyday willy-nilly. There is no need to specify the specific version numbers of transitive dependencies, if one keeps a lock file that pins those exact versions and checksums of transitive dependencies, and one doesn't upgrade willy-nilly all the time. Make upgrading dependencies a conscious choice, and perhaps have a policy of at most upgrading every X days.
I don't think it's accurate to envision that the average team using the npm ecosystem is upgrading their dependencies daily. Rather, the problem is that modifying your direct deps (e.g. adding a package, upgrading a package) requires modifying transitive deps.
So yeah, ~everyone is using a lockfile with checksums. But even if I think really hard about installing XYZ@1.2.3 package, and check that the lockfile diff is reasonable, I'm not manually auditing the whole supply chain (I'd get fired for getting nothing done). And a single dependency change that I choose to make can affect a substantial number of transitive deps.
My idea is, that they do _not_ upgrade their dependencies daily, because that is what is causing the issue. People don't pin all their versions and checksums properly, and the next time they run `npm install` they get a new version of some library. I don't even want to see any "@^1.2" or whatever the syntax was. Also they should be running `npm ci`.
I have seen this multiple times with people from various backgrounds and in frontend as well as backend. People still think like "Lets auto upgrade patch releases, so that we always get the bugfixes." or "Lets upgrade quickly, so that we deal with changes right away, before accumulating the work.". But they don't think properly about security and reproducibility.
I would be careful assuming that a lack of performance was responsible for the internships not converting.
At my company, I've recently seen a lot of cases where interns don't get return offers. Maybe they're all underperforming for pre-entry-level, but I seriously doubt that.
I will also point out that hiring is rarely skill based. I mean seriously. You can be great and not get hired, and you can be a liability and get hired anyway. This was true even before the post-COVID squeeze.
Yeah, our team of two gets two interns a semester. We cannot convert them to full time as there is no position open. Complete hiring freeze since 2022.
We paused hiring fresh grads, but still hire interns, and those who prove themselves get full-time offers. We've found internships to be a great pipeline to great hires over the years.
We've had several candidates with completed bachelor's degrees apply for internships, prove themselves, and get full-time jobs that way. This "back door" job hiring pathway might work elsewhere as well.
Same here. We pay interns pretty well and we invest a lot in them during their internship. It doesn't make sense for us (and I imagine others) to take in interns and then not hire the good ones. That's the entire reason we do internships to start with.
This is obvious but it needs to be said: Backend languages are designed for backend work, and frontend languages for frontend work. Where this becomes a real pain point is where the design goals of the language run counter, and probably the chief one is around modelling business rules.
It is the job of the backend to constrain itself down into fitting the business rules and nothing else, and backend languages aid this by allowing one to model well-defined types and put defensive guards and deal with bad behaviour in a number of ways (e.g. there is often a distinction between a runtime error and non-runtime errors).
It is the job of the frontend (or at least, what my ideal frontend would be) to have good UX and to delegate to the backend for business rules. Indeed in my ideal, the backend would dictate the HTML content to the greatest degree possible. The coding that is needed on the frontend is for DOM manipulation to add some dynamic feel to the UI, and avoid full page reloads for small adjustments. A dynamically typed scripting language (e.g. Javascript) is good for this, because it is quick to hack and tweak an experimental view, review it with users, adjust, and repeat (which is at least how I go about getting the UX good enough).
Using a typed backend language on the frontend would get in the way of me just hacking the view, which is the appropriate mode of programming for a dumb client (dumb client being my ideal).
Also, and where it does tie in with my original comment, is that I do think using a backend language on the frontend invites putting business rules in the UI code. I think that because I've been on projects where that has happened, and I understand the instinct- why pivot from my frontend coding and go and figure out what I need to modify on the backend to code a feature when it is seemingly easy for me to model it on the frontend just as well? Infact, why not put all the logic in the frontend and let the backend be a dumb CRUD REST API/a GraphQL layer above the DB?
Conversely, if it is not easy to do much beyond DOM manipulation on the frontend (because the language and setup don't make it easy), and I am forced to modify the business rules in the backend, then fantastic.
That would also avoid the problem with this syntax, that it's not a valid Go file (it doesn't start with `package ...` and I don't think a bare top-level string is valid), which lots of editors will be pretty unhappy about.
Definitely not a minor feedback, there's no reason to write go in a .js file. Vite/rollup are perfectly able to "load" certain file types and parse them however you like.
I stand firm that there's no reason to write go in a .js file other than ragebaiting, especially with that "use" directive that clearly everyone is hating on Twitter at the moment (due to Vercel, etc)
To be clear I'm fine with importing .go from JS, it's the "go in file.js" thing I don't like.
Also, if most developers are using one editor, configure that editor to run format and auto-fix lint errors. That probably cleans up the majority of unexpected CI failures.