Hey! I didn't realize this wasn't even posted by the creator of the library. Building shit and launching is hard, don't let it dissuade you from putting stuff out there though!
Also, check out base-ui. Radix is fine, but base ui has generally better primitives and is being actively developed
Hey man, if you ever see this, not your fault it ended up on HN early! I'm sure this is solid for your usecase. That's just something that would dissuade me from choosing it!
The fact that there's no tangible plan for any plugin support in Turbopack is actually what made me not choose Next.js.
The answer for people who need basically any build plugin is "use the webpack mode", and I have zero faith in Vercel maintaining that past the next major version.
I guess we'll see whether they figure out a story for plugins by then.
it is true that our plugin story is not fully fleshed out. We have good support for webpack loaders and have observed that that solves many (though not all usecases). This of course is one of the reasons we are still supporting webpack
why would you bid the highest price you can afford in an auction? the seller agreed to auction the thing; they could have just offered it for a set price.
Do you not know how ebay works? You put in the maximum price you're willing to pay, and if you win you're paying 2nd highest bid + 1. So you don't save any money by starting with a low bid.
From what I've seen discussed, it seems some percentage of "sniping" is to attempt to obtain both "winning bid" and "lowest possible price" (note, not the same as "max willing to pay for the same item"). The sniper is trying to hide interest, so as not to attract other interested bidders, and therefore grab "a great deal" of a small increment above the starting bid price.
And this probably appears to work enough times in the snipers favor to trick them into thinking it is a winning strategy, whereas they likely would have won the same auctions in the end by just bidding that 'minimum' as their maximum bid. But as they can't easily (i.e., without expense) A/B test their strategy, they get no feedback that sniping isn't really helping them like they think it is helping them.
> But as they can't easily (i.e., without expense) A/B test their strategy
There also isn't really any detriment. At worst, the sniper is making the same bid they would have made otherwise. If the opposing bidders are not purely rational, and have not put in their actual maximum bid, then sniping can deprive them of that opportunity and thus lowers the hammer price.
And bidders are not purely rational, especially when the items are not purely utilitarian. Getting notifications that you have been outbid has an emotional effect, as does having time to think about raising the bid.
they notify the bidder when they're outbid, and the incremental price increases can make it tempting for someone to adjust their idea of their max price. sniping deprives them of that opportunity.
let me clarify the intent of my comment then. Human rights is not a "two-sides" issue to be debated. If you attempt to reduce an affirmation of human rights for all people to a "political agenda", I will call out your conservative dogwhistle. I don't care how that's received.
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.
reply