sentry-javascript VS large-monorepo

I hope this tone comes across correctly as just a suggestion: I get a lot of mileage out of the "Send Feedback" option in DDG, which they claim actual humans do read. It can help move bug reports out of these HN threads into a more context-aware flow, and also makes me feel like any bad outcome has the possibility of improving, unlike systems that don't provide a "I feel bad about this experience" button

If you were thus inclined, https://gitlab.com/glitchtip/glitchtip#glitchtip is the actual open source Sentry implementation which (as far as I know) would enable gluing https://docs.sentry.io/platforms/javascript/user-feedback/#u... to the search results (which itself is still MIT: https://github.com/getsentry/sentry-javascript/blob/7.102.1/... )

Sentry JavaScript - Sentry, renowned for its comprehensive solutions in frontend monitoring and error logging, recently adopted Nx for their official JavaScript SDK. This move integrates Nx's capabilities into their monorepo, containing packages for popular frontend and Node.js backend integrations. They also published a blog post on the benefits they've seen following the adoption of Nx in their monorepo (hint: reducing CI times by 35%).

Running Sentry Wizard... version: 3.13.0 | sentry-cli version: 1.75.2 Sentry Wizard will help you to configure your project Thank you for using Sentry :) Skipping connection to Sentry due files already patched ┌ Sentry Next.js Wizard │ ◇ ────────────────────────────────────────────────────────────────────────────╮ │ │ │ The Sentry Next.js Wizard will help you set up Sentry for your application. │ │ Thank you for using Sentry :) │ │ │ │ Version: 3.13.0 │ │ │ ├───────────────────────────────────────────────────────────────────────────────╯ │ ◇ Are you using Sentry SaaS or self-hosted Sentry? │ Sentry SaaS (sentry.io) │ ◇ Do you already have a Sentry account? │ Yes │ ● If the browser window didn't open automatically, please open the following link to log into Sentry: │ │ https://sentry.io/account/settings/wizard/authtoken123/ │ ◇ Login complete. │ ◇ Select your Sentry project. │ myproject-126kk132c/javascript-nextjs-f9 │ ◇ Installed @sentry/nextjs with NPM. │ ◆ Created fresh sentry.server.config.ts. │ ◆ Created fresh sentry.client.config.ts. │ ◆ Created fresh sentry.edge.config.ts. │ ◆ Added Sentry configuration to next.config.js. (you probably want to clean this up a bit!) │ ◆ Created src\app\sentry-example-page\page.jsx. │ ◆ Created src\app\api\sentry-example-api\route.js. │ ◆ Created .sentryclirc with auth token for you to test uploading source maps locally. │ ◆ Added .sentryclirc to .gitignore. │ └ Everything is set up! You can validate your setup by starting your dev environment (`next dev`) and visiting "/sentry-example-page". If you encounter any issues, let us know here: https://github.com/getsentry/sentry-javascript/issues 🎉 Successfully set up Sentry for your project 🎉

We've just started this initiative and have already been able to help Sentry get optimized with task caching and task pipeline optimizations for their workspace!

In addition to the network call data we already attached, that does go through data PII scrubbing on the edges as you mentioned, we're discussing capturing request/response body. We even talked about it today: https://github.com/getsentry/sentry-javascript/issues/7103

Avoiding any PII from getting into the system is always top of mind. And we're considering this as an opt-in regardless of scrubbing on the edge ingestion service.

Add Sentry’s Next.js SDK to your next.js projects.

Get started with Sentry for Electron and drop us a line on GitHub, Twitter, or our Discord. And if you’re new to Sentry, you can try it for free today or write to [email protected] to get started.

Great idea! #4118

The Nx daemon has seen significant enhancements, notably through the use of Rust to calculate file hashes behind the scenes. This improvement not only speeds up the start-up times but also optimizes performance even without the daemon, especially on CI environments where the daemon isn't used. The benchmark results at this repo showcase the remarkable speed improvements, making Nx competitive with native code solutions while maintaining the accessibility and flexibility of Node.js. Nx is still Node-first, so contributions are easier and only the most performance-critical parts of Nx are native code.

At Nx, we’ve heavily embraced Typescript from the beginning and we’ve been very happy with that decision. Nx also stands as the fastest JS monorepo tool available, demonstrating that adopting TypeScript does not necessarily compromise speed. However, we don't stop here. To push the boundaries further, we started to rewrite the most performance critical and computationally intensive parts of the Nx core in Rust.

You can see our results and the details of the benchmark - and even run the benchmarks for yourself in this repo.

Performance is at the core of what we do at Nx. Hence it isn't surprising that Nx is the fastest JS-based monorepo solution out there. We've shown that a couple of times. But every millisecond counts! As such, we decided to experiment with Rust to see whether we could further optimize our project graph creation as well as the hasher function that is used for the computation cache.

Speed - we drastically improved the speed of Nx, making it the fastest monorepo solution in the frontend space.

Up until Lerna v4, either the p-map or p-queue npm packages have been used to delegate the task scheduling. With v5.1 we introduced nx as an additional mechanism to schedule tasks. The advantage? Nx has caching built-in, which also gives Lerna caching support, making it lightning fast. A recent benchmark test resulted in Lerna being 2.5x faster than Lage and around 4x faster than Turbo (as of Oct 2022; test it out by yourself).

Nx is faster than most of the current available alternatives. See the corresponding benchmark repository

Delegating task scheduling to Nx allows to speed up any Lerna workspace in the range of 2-10 times. Check out our public benchmark which compares Lerna with other popular JS based monorepo tools.

(as always, feel free to reproduce it here)

But let's do some more real "apples-to-apples" comparison of Lerna's speed with useNx enabled. For benchmarking Nx we have set up a repo in the past which we regularly use to measure the speed of new Nx releases with other similar tools on the market such as Lage and Turborepo: https://github.com/vsavkin/large-monorepo. We now added Lerna+Nx (Lerna with useNx enabled) to that repo to measure the impact.