Alfredo Lopez

@ScriptedAlchemy Ah got it, so technically it’s all bc they bundled webpack? If I were to patch Next to remove that and the require hooks, it would work? I’m already patching Next for other things so I’d be highly interested in that.

its because i deep import from webpack core modules and next bundles webpack so you cant deep import. It used to work with NEXT_PRIVATE_WEBPACK basically using some of their internal dev vars, but that now no longer works due to how they patch require hooks. some race condition forms and we end up loading 2 copies of webpack which breaks the singletons of webpack-sources. These are not problems i have with rspack because 80% of my code is in the rust binary already, no need to deep import anything because my stuff is in the core already. If i moved v2 back into webpack core, it would work. But again, i have better things to do with my tokens

Its official. Im giving up on nextjs & module federation webpack plugin. Deleted the package, writing new version of package for rspack only

@Kpaxs The biggest nuance here, when you fix something, you want to be the "Glue" and not the "Gap Filler". You can fix/do something while bringing people together (even if it isn't really required), and it makes a world of difference.

Here a controversial take: most of the authority that exists in any organization was never formally granted to anyone. It was assumed, exercised, and then retroactively legitimized by the fact that it worked.

@brianchaley Ocean waves. Ocean waves.

c’mon man

@VicVijayakumar This is the equivalent of getting up from the couch after sitting for a while. Everything's good, but give me a sec!

🤨

@Una 🙌🏻

@lfredolo We’re working on it 👀

🎉 And we're live! 🎉 We just launched CSS Wrapped 2025: our annual recap of all things CSS & web UI that landed in Chrome over the course of the year. 🚀 This is a big one! We highlighted 22 new features to help you build better on the web. Check out: chrome.dev/css-wrapped-20…

@_AhmadAwais @jaredpalmer I ask them to explain their *best* work/invention/etc, then ask if they had to do it all over again, what they would change. Folks who are both proud of their past work and, at the same time, the most critical about it in hindsight are, IMO, the ones who most display this trait.

@jaredpalmer how do you judge for that in an interview :P

You need to hire people who are constitutionally incapable of watching something be broken without fixing it

@addyosmani @googlechrome What an incredible run, Addy! The whole dev community (especially web perf!) is immesurably better thanks to your contributions! Congrats! 🙇🙌

After ~14 years working on Chrome, it's time for a new chapter. When I joined the @googlechrome team, I walked into a group that believed the web could be fast, simple, safe, and a joy to build on. I still believe that today, and I am continually in awe of what the team and the broader web community do every day. My last day with Chrome will be today. After that, I am excited to be moving into a new role at Google. More on that soon. Over the years I have been lucky enough to work with many teams across Chrome on new APIs, performance, DevTools, benchmarks, extensions, automation, and the broader evolution of the web platform. From Core Web Vitals and Lighthouse, to @ChromeDevTools and CDP, to efforts like Speedometer, Interop, Baseline, PWAs, AI, and our collaborations with frameworks and platforms, the constant has been the same: make the web faster, more reliable, and easier to build on. What I will remember most is not any single launch, but the way this team builds. Listening to users and developers. Measuring. Sweating the details. Making hard calls with empathy. Taking the long view while still shipping with urgency. That culture is the reason Chrome has had the impact it has on the ecosystem. To everyone in the @ChromiumDev and web community I have had the chance to work with: thank you. Thank you for the trust, the feedback, the late nights, the careful reviews, and the countless ways you pushed the platform and its tooling forward. It has been a privilege to learn from you and to build alongside you. I will still be cheering for Chrome and for the open web. If we have worked together or share an interest in the future of the web, AI, and developer experience, I would love to stay in touch as this next chapter begins.

I’d honestly pay a premium for a movie theater experience where people are required to put their phones in a faraday cage bag. I’m sure the Alamo Drafthouse figured out it’s easier/cheaper to have someone monitor, but one can hope @AMCTheatres 🙏

@_bgwoodruff @timneutkens That’s great to know, even though the docs don’t reflect that sentiment. Looking forward to get on board when that lands!

@lfredolo @timneutkens We will 100% support a plugin/lifecycle hook API. It's on the roadmap. We know it's a huge blocker. Plugins will use the same or similar infra as webpack loaders for JS execution, which is why we want to fix that first.

Wait, so Turbopack has no Plugin API or plans to do so? For some reason, I thought babel plugins was the dealbreaker from early on, but no compilation hooks at all? Huge bummer.

@timneutkens We've been struggling with how Next now hardcodes ENV and assetPrefix at build time. Dynamic ENV is much easier, but we had to create a plugin to support a dynamic asset prefix. Amazingly, you can do this sort of thing in Webpack. gist.github.com/lfre/55f49643c…

@timneutkens My bad, this is kind of what I gathered from v0, which reads a bit differently. Still, you're confirming it's nowhere near the roadmap, which isn't great. Not every use case should be supported upstream, which is the whole point of providing lifecycle hooks.

@ryanflorence @ryan_t_brown Believing in a superior being is an evolutionary trait for sure. Humans over time figured out it can be used as a form of control, and God === Religion(s). It’s rational to believe in God, but irrational (fear) that I can’t do A/B/C bc some old dude(s) said it’d make God mad. 🤷🏻‍♂️

@ryan_t_brown Sure. I'm not making an argument for God's existence. I'm making an argument that belief in God is just as rational as what you have to believe if you limit yourself to our current observations of the universe.

One day I realized the fact that we exist at all is enough rationale to believe in God The whole universe exploding from nothing is just as bizarre as being the child of a sky wizard who loves me The wild part is confirmation of God's love follows the belief and strengthens me

@rickyfm @KirillTregubov_ I think this can be opt-in or dev mode enabled like other warnings. This is just one example of many, especially when you’re consuming external HTML from a headless CMS. Appreciate the reply nonetheless!

@lfredolo @KirillTregubov_ It’s really a question of whether we should, not if we could. Supporting it would be a performance tax when you can just add a <tbody> to avoid the tax, and there are weird cases to consider. Ryan explained it well here:

Was this edited to make it look worse? This is what that error has said for the past 10 years. The explanation is there in the message: the browser inserts a <tbody> which causes a mismatch.

@jaredpalmer @github Oh boy, SO many but first: - Don’t hide update with rebase,& don’t make force pushes look like the worst thing ever in the UI. - “warning” as result for PR Checks. - Custom merge templates like Gitlab, where you can use macro variables e.g %{commit_sha} docs.gitlab.com/user/project/d…

How can we make @GitHub Pull Request and code review experience better?

@KirillTregubov_ @rickyfm What are you on about dude? My tweet was asking a question, but you clearly don’t understand the issue and chime in with boilerplate advice then lash out when corrected. 🤷 That’s now how you get better at things bud. Best of luck.

@lfredolo @rickyfm If you believe what you are saying, open the PR in the React repository and add the feature yourself. But I'm willing to bet you're not going to do that, and instead will continue to complain, or even worse, straight up lie about it like the original quoted author.

@KirillTregubov_ @rickyfm That’s the whole point of my original tweet. If React is not going to adhere to the same spec HTML parsers follow then it should warn you about invalid HTML output when is created. This doesn’t help with browser extensions, 3rd party, but it’s silly when it’s self-inflicted.

@lfredolo @rickyfm This isn't an server rendering error. The server render completed successfully and generated the HTML + RSC Payload. The error is a client render error, so that's the correct place to report it as such. Enable nextjs.org/docs/app/api-r… and you can see the error in your terminal.