DEV Community: lassiecoder

How to fix React Native build errors: Find the real error in Gradle, Xcode and metro logs

lassiecoder — Thu, 15 Oct 2026 13:02:55 +0000

When a React Native build fails, the last line of the log ("BUILD FAILED", or a red screen on the device) almost never tells you the cause. The real error is somewhere above it, in Gradle, Xcode, CocoaPods, Metro or the device log.

This guide covers how to find it fast, with fixes for six errors React Native developers run into all the time. For each one I'll show the raw error and what rn-build-doctor, a free, open-source CLI I built, reports for it. All the output below is real, from React Native 0.86 and 0.87 apps, an Expo SDK 57 project, Xcode 26 and an Android 14 emulator.

lassiecoder / rn-build-doctor

Evidence-based diagnostics for React Native and Expo build, release, and startup failures.

RN Build Doctor

Evidence-based diagnostics for React Native and Expo build, release, and startup failures.

rn-build-doctor reads your project and the logs you give it, runs deterministic checks, and tells you:

What failed: the primary error, not the final BUILD FAILED line.
What evidence supports it: log excerpts with original line numbers, and the project files and versions involved.
What to check next: specific steps, with a way to verify the fix.
How to share it safely: a redacted Markdown or JSON report you can review before posting.

It never guesses silently. When a log doesn't match a supported pattern, it says "No supported diagnosis" and shows the first error lines instead of inventing a cause. AI is optional, opt-in, and shown separately from verified findings.

Status: 0.1 preview. The rule catalog is narrow on purpose: 40 rules, each with fixtures and a cited source. See supported checks and known…

View on GitHub

Find it on NPM

Quick start

You don't need to install anything. Run these from your project root (the folder with package.json), with Node.js 22.12 or later:

# Android build fails
(cd android && ./gradlew assembleDebug) 2>&1 | npx rn-build-doctor analyze -

# iOS build fails
xcodebuild -workspace ios/MyApp.xcworkspace -scheme MyApp -sdk iphonesimulator build 2>&1 | npx rn-build-doctor analyze -

# pod install fails
(cd ios && pod install) 2>&1 | npx rn-build-doctor analyze -

# JavaScript bundling fails
npx expo export 2>&1 | npx rn-build-doctor analyze -

# App crashes or shows a red screen on Android
adb logcat -d | npx rn-build-doctor analyze -

# Check the project before building
npx rn-build-doctor scan

Two details that matter:

Add 2>&1 so errors printed to stderr are included.
Keep the tool running from the project root (that's why the Gradle command is in parentheses). It reads package.json, node_modules, gradle.properties and your Android/iOS config to tell apart causes that produce the same error text.

Every finding shows what failed, the log lines that prove it (with line numbers), next steps, and how to verify the fix.

Why the last line lies

Here is the bottom of a real failed Gradle build:

Everything you see first is generic: "Run with --stacktrace", deprecation notices, BUILD FAILED. The useful part is the "What went wrong" section further up, and in bigger builds it can be hundreds of lines above. Rule one of debugging React Native builds: search for the earliest specific error, not the last line.

1. Manifest merger failed: uses-sdk:minSdkVersion 24 cannot be smaller than version 26

The raw error:

Execution failed for task ':app:processDebugMainManifest'.
> Manifest merger failed : uses-sdk:minSdkVersion 24 cannot be smaller than version 26 declared in library [androidx.health.connect:connect-client:1.1.0]

What it means: a library you added (directly or through a React Native package) only supports Android 8.0 (API 26) and up, but your app says it supports API 24. Gradle refuses to build an app that would install on devices the library doesn't support.

What rn-build-doctor reports:

The fix, in order of preference:

Raise minSdkVersion to 26 in android/build.gradle (the minSdkVersion value in buildscript.ext). In Expo, set android.minSdkVersion with expo-build-properties.
Or use a version of the library (or of the React Native package that pulls it in) that supports your minSdk. Run cd android && ./gradlew :app:dependencies to see who requires it.
Only use tools:overrideLibrary if every call into the library checks the API level at runtime. Otherwise the app crashes on older devices.

2. Unable to load script. Make sure you're running Metro (red screen)

The raw message (from adb logcat):

W unknown:BridgelessReact: ReactHost{0}.handleHostException(message = "Unable to load script.
Make sure you're running Metro or that your bundle 'index.android.bundle' is packaged correctly for release.

What it means: a debug build loads its JavaScript from the Metro dev server, and the app couldn't reach it. With the New Architecture (the default since React Native 0.76), this doesn't crash the app. You get a red screen and only a warning in logcat, which makes it easy to miss if you're searching the log for crashes.

What rn-build-doctor reports:

The fix:

npx react-native start      # or: npx expo start
adb reverse tcp:8081 tcp:8081   # for a USB-connected Android device

On Wi-Fi, set the dev server address in the dev menu to your computer's IP and port 8081. If this happens in a release build, the bundle wasn't packaged: check that the createBundleReleaseJsAndAssets task ran.

3. Signing for "MyApp" requires a development team

The raw error (xcodebuild):

error: Signing for "MyApp" requires a development team. Select a development team in the Signing & Capabilities editor.

What it means: you're building for a real device (or archiving), and the iOS target has no DEVELOPMENT_TEAM set, so Xcode can't sign the app.

What rn-build-doctor reports:

The fix: in Xcode, select the target → Signing & Capabilities → choose a team. In CI, pass DEVELOPMENT_TEAM=YOURTEAMID to xcodebuild. With Expo/EAS, let EAS manage credentials (eas credentials) or set ios.appleTeamId.

4. Unrecognized VM option 'MaxPermSize=512m'

The raw error:

Unable to start the daemon process.
Unrecognized VM option 'MaxPermSize=512m'
Error: Could not create the Java Virtual Machine.

What it means: your android/gradle.properties still has -XX:MaxPermSize in org.gradle.jvmargs, a leftover from old React Native templates. JDK 8 removed the permanent generation, and newer JDKs refuse to start with that option, so Gradle can't even launch. You'll usually hit this when an older project meets a newer JDK.

What rn-build-doctor reports (when run from the project, it also points to the exact gradle.properties line):

The fix: remove -XX:MaxPermSize=512m from org.gradle.jvmargs (use -XX:MaxMetaspaceSize if you need a limit), then run cd android && ./gradlew --stop so no old daemon is reused.

5. Android Gradle plugin requires Java 17 to run. You are currently using Java 11

What it means: Android Gradle Plugin 8 and later need JDK 17, and Gradle picked up an older JDK.

rn-build-doctor's output:

ERROR F1 Gradle is running on Java 11, but the Android Gradle Plugin requires Java 17
      android.agp-requires-newer-jdk · confidence high · android
      Next steps:
      1. Install JDK 17. For example, the React Native docs recommend Azul Zulu 17.
      2. Point JAVA_HOME at the JDK 17 installation, or set org.gradle.java.home in android/gradle.properties.
      3. If the build runs inside Android Studio, set Settings > Build, Execution, Deployment > Build Tools > Gradle > Gradle JDK.
      4. Stop old daemons with `cd android && ./gradlew --stop`.

Gradle uses the JDK from org.gradle.java.home first, then JAVA_HOME, then the java on your PATH, and Android Studio has its own Gradle JDK setting. That's why it can work in Android Studio and fail in the terminal (or the other way round). npx rn-build-doctor scan shows which JDK your shell is using before you build.

6. Unable to resolve module X from App.tsx (Metro)

The raw error:

error Unable to resolve module lottie-react-native from /Users/dev/MyApp/App.tsx: lottie-react-native could not be found within the project or in these directories:
  node_modules

The same error text has different causes: the package isn't installed, it's installed but not in package.json, Metro's cache is stale, a path alias isn't configured, or a relative import has the wrong letter case (which works on macOS but fails on Linux CI and EAS). Because rn-build-doctor reads package.json and node_modules, it tells them apart:

ERROR F1 Unable to resolve 'lottie-react-native' from App.tsx
      javascript.unable-to-resolve-module · confidence high · javascript
      Package 'lottie-react-native' is imported but isn't declared in package.json and isn't installed.
      Next steps:
      1. Install it with your package manager (for example `npm install lottie-react-native`).

Bonus: Kotlin compile errors after an upgrade

Native compile errors are easy to lose in Gradle output. rn-build-doctor pulls out the file, line and column, and if the file is inside node_modules, it tells you which npm package it belongs to (usually a library that doesn't support your React Native version yet):

ERROR F1 Kotlin compile error in MainApplication.kt:28:24: Unresolved reference 'PackageList'.
      The Kotlin compiler reported 2 errors, so :app:compileDebugKotlin failed.

Use it in CI (GitHub Actions)

- run: |
    set -o pipefail   # without it, the step takes tee's exit code and never fails
    npx expo export --platform android 2>&1 | tee build.log
- if: failure()
  run: npx rn-build-doctor analyze build.log && npx rn-build-doctor report --output "$GITHUB_STEP_SUMMARY"

The diagnosis appears in the job summary. Add --fail-on error to scan or analyze to fail a pipeline on findings.

Share a build failure safely

npx rn-build-doctor report --output build-report.md

This creates a Markdown report you can attach to a GitHub issue or paste into Slack. It's redacted (tokens, keys, passwords, auth headers, your home directory), and .env values are never read. scan and analyze run fully offline, and the test suite fails if they open a network connection. Redaction is best-effort, so give the report a quick read before sharing.

When it doesn't know the error

It has 40 checks today. If your failure isn't one of them, it says "No supported diagnosis" and shows the first error lines instead of guessing. There's also an optional, opt-in AI explanation (npx rn-build-doctor explain --dry-run shows exactly what would be sent first).

If you hit a failure it doesn't recognize, please open an issue with the anonymized log. Real logs are how new checks get added.

FAQ

Does it work with Expo?

Yes. It understands Expo CLI output, EAS build logs, app config, config plugins, SDK version mismatches and EXPO_PUBLIC_ environment variables.

Does it send my logs anywhere?

No. scan, analyze and report never make network requests. Only the optional explain command contacts an AI provider, after showing you what it will send and asking for confirmation.

Do I need to install it?

No. npx rn-build-doctor runs the latest version. You can also add it as a dev dependency: npm install --save-dev rn-build-doctor.

Does it fix my project automatically?

No, on purpose. It only reads files and recommends changes, so you stay in control of your project.

If this helped, a ⭐ on GitHub helps other React Native developers find it.

I built a Google Ads Audit tool in 48 hours and here's what happened

lassiecoder — Tue, 16 Jun 2026 11:27:23 +0000

Last weekend I gave myself a challenge: find a real problem, build something that solves it, and ship it before Monday. Here's the honest story of what I built, why, and what I learned.

The Problem I Kept Seeing

Small businesses waste 25–40% of their Google Ads budget every month. Not because they're careless, because Google's dashboard makes it nearly impossible to know what's actually working.

You log in and see clicks. Impressions. CTR. A bunch of numbers that look like progress but don't answer the one question that matters: is this making me money?

I looked at the existing tools trying to solve this. Every single one WordStream, Opteo, TrueClicks, Adalysis, is built for agencies and PPC professionals managing $25K+/month. They're powerful, complex, and start at $130/month.

Nobody built one for the dentist or plumber spending $500/month who just needs one clear answer in plain English.

That's the gap I decided to fill.

The Idea: A Waste Score

I wanted one number. Like a credit score, but for your Google Ads account.

Connect your account → get a score out of 100 → see exactly where the waste is → get 3 specific things to fix today.

No jargon. No agency. No 47-page report.

The tool would check:
Keywords spending money for 90+ days with zero conversions
Whether conversion tracking is set up correctly (most accounts have this broken)
Budget concentration, is all your money in one campaign with no backup?
Search terms triggering your ads that have nothing to do with your business

Then Claude AI turns the raw data into plain English fixes a non-marketer can actually act on.

Saturday: Building the Core

I started Saturday morning with a blank Next.js project and one goal: get a real Google Ads account connected and show the waste data by end of day.

The hardest part wasn't the code. It was the Google Ads API approval process, Google requires a manual review of your developer token before you can pull real account data. I submitted the application and built everything else while waiting.

By Saturday evening I had:
Google OAuth working, users could connect their ads account in one click
The audit engine pulling campaign, keyword, and conversion data
Claude AI turning that raw data into a plain-English Waste Score and fixes
A basic report page showing the results

The Claude integration was genuinely the most satisfying part to build. Feeding messy spreadsheet-like API data in and getting back "Pause these 6 keywords, they've cost you $340 this month with zero sales" felt like magic.

Sunday: Polish and Launch

Sunday was about making it feel real.

I added Stripe so the free tier shows your Waste Score and top fix, and the paid tier ($29/month) unlocks the full report, negative keyword CSV export, and PDF download.

Then I built the landing page. The most important element was a demo report card, showing a sample audit with a real dollar amount of wasted spend. People need to see what they're getting before they'll connect their account.

By Sunday evening, adsiftly.com was live on Vercel.

I submitted it to ProductHunt, created an IndieHackers page, and wrote this article.

The One Thing Nobody Warned Me About

The Google Ads developer token takes days to approve.

You apply through your Google Ads Manager account, submit a form describing what you're building, and then wait. Google reviews it manually. There's no way to speed it up.

During this waiting period your token only has "Test Account Access", you can query test accounts but not real ones.

I built the entire product not knowing if the core API access would even be approved. That's a real risk for a weekend project.

If you're building anything on the Google Ads API: apply for the developer token on day zero, before you write a single line of code.

What I'd Do Differently

Ship the landing page first, build second.
I built the product then launched. Should have been: landing page → collect waitlist emails → validate demand → build. I could have tested the idea in 4 hours instead of 48.

One paid tier, not three.
I launched with Free / $39 / $149. The moment I added a third pricing tier I started second-guessing which features belong where. For a weekend launch, one paid tier is enough.

Mock data is your best friend.
Don't wait for OAuth and API connections to test your UI. Build with realistic fake data first, wire up the real API last. I lost hours waiting for things to connect when I could have been building.

Where It Stands Now

AdSiftly is live. The waitlist is open. The developer token is pending.

Revenue: $0 (being honest).
Learnings: a lot.

The real launch happens when Google approves the developer token and real users can connect real accounts. Until then, everything is validation, and validation is the most important thing at this stage.

The best side projects aren't the ones with the most features. They're the ones that solve one boring, specific, painful problem for one clear group of people.

Wasted Google Ads spend is boring. Specific. Painful. And almost every small business running ads has it.

That's enough to build on.

Try AdSiftly free at adsiftly.com — no credit card, takes 60 seconds.

If you've ever run Google Ads and felt confused by the results, this is built for you.

How Claude Code’s creator ships 50–100 PR’s per week

lassiecoder — Mon, 16 Feb 2026 15:20:46 +0000

When Boris Cherny, the creator of Claude Code, shared his daily workflow on X, the development community took notice. Not because of some revolutionary technique or complex setup, but for the opposite reason: his approach is remarkably straightforward. And that’s precisely why it works.

If you’re looking to supercharge your development workflow with AI, here’s how one of the people building these tools actually uses them.

The core philosophy: Parallelism over speed

Boris runs approximately 10 Claude sessions in parallel at any given time. Instead of babysitting each one, he relies on system notifications to alert him when human input is needed. This approach transforms AI from a back-and-forth conversation tool into something more akin to having a team of junior developers working simultaneously on different tasks.

The key insight here is understanding that AI assistance doesn’t have to be sequential. You’re not limited to one task at a time. By spinning up multiple sessions, you’re essentially multiplying your capacity to tackle problems.

Opus 4.5 with thinking: Slower tokens, faster results

While many developers gravitate toward faster models for quick iterations, Boris exclusively uses Claude Opus 4.5 with thinking enabled. Yes, it’s slower per token. But here’s the counterintuitive truth: it’s faster overall.

Why? Because it requires far less human steering. When you use a more capable model that can reason through problems, you spend less time course-correcting, clarifying, and re-explaining. The AI gets it right more often on the first try, which means you’re not stuck in revision loops.

Think of it like hiring: you might pay more per hour for a senior developer, but they’ll complete the project in a fraction of the time a junior would need.

The 2,500-token secret weapon

The Claude Code team maintains a single shared Claude.md file, checked directly into their Git repository. Whenever Claude behaves incorrectly or misunderstands something, they add a new instruction to this file.

The surprising part? After continuous refinement, this file sits at just around 2,500 tokens. That’s remarkably concise for a document that encodes the team’s entire workflow, conventions, and common pitfalls.

This approach is brilliant in its simplicity. Instead of re-explaining your coding standards, architectural decisions, and preferences in every new conversation, you build up a knowledge base that travels with your code. It’s version-controlled, it’s collaborative, and it evolves with your project.

Plan first, execute once

Boris starts most sessions in plan mode. He iterates on the plan until it feels solid and well-thought-out. Only then does he switch to autonomous mode.

The result? The task usually gets done in one shot.

This two-phase approach mirrors how experienced developers naturally work. You don’t just start coding immediately. You think through the problem, consider edge cases, map out the architecture, and only then do you write code. By forcing this separation with AI, you ensure the execution phase has clear direction.

Sub-agents for specialized tasks

Rather than using Claude as a monolithic tool, Boris employs specialized sub-agents for specific purposes:

Code Simplifier handles post-generation cleanup, refactoring verbose code into something more maintainable.

Verify App runs end-to-end testing to ensure the generated code actually works in practice.

This division of labor is another stroke of genius. Different tasks require different contexts and goals. By creating specialized agents, you’re optimizing each one for its specific role rather than trying to make a single prompt do everything.

Let Claude verify its own work

Perhaps the most interesting aspect of Boris’s workflow is his strong belief in letting Claude verify its own work. He allows it to use a Chrome extension to open a browser, test the UI, and iterate until the code actually functions correctly.

This creates a feedback loop that’s incredibly powerful. Instead of you manually testing and reporting back what’s broken, the AI can see the results of its work and self-correct. It’s the difference between giving someone directions and letting them use GPS.

The output: 50–100 pull requests per week

With this setup, Boris completes approximately 50 to 100 pull requests per week. Let that sink in. That’s anywhere from 10 to 20 PRs per day.

For context, many developers consider 5–10 meaningful PRs per week to be highly productive. Boris is operating at roughly 10x that rate.

Why vanilla workflow works?

In the comments on his original post, many people pointed out that his workflow is pretty vanilla and straightforward. There’s no exotic prompting technique, no complex orchestration system, no proprietary tooling.

And that’s exactly why it works so well.

The most sustainable, scalable workflows aren’t built on clever hacks or cutting-edge techniques that might break with the next model update. They’re built on solid principles: parallelism, proper planning, specialization, and verification.

Key takeaways for your workflow

If you want to adopt Boris’s approach, here are the core principles to implement:

Run multiple sessions in parallel. Don’t wait for one task to complete before starting another. Let the AI work on several things simultaneously while you focus on high-level orchestration.

Invest in better models upfront. The most capable model with extended reasoning might seem slower, but it saves time by getting things right the first time.

Build and maintain a project-specific instruction file. Create your own Claude.md that captures your conventions, common issues, and preferences. Keep it concise and version-controlled.

Separate planning from execution. Get the plan right before switching to autonomous mode. A solid plan executed once beats a vague idea iterated ten times.

Create specialized agents. Instead of one general-purpose prompt, build focused sub-agents for cleanup, testing, and other recurring tasks.

Enable self-verification. Give your AI the tools to check its own work and iterate without constant human intervention.

The future is already here

What’s remarkable about Boris’s workflow isn’t that it’s revolutionary. It’s that it’s achievable today, with tools that are publicly available. You don’t need to wait for the next model release or some breakthrough in AI capabilities.

The gap between where most developers are and where they could be isn’t technological. It’s methodological. Boris has simply figured out how to structure his work to leverage AI’s strengths while minimizing its weaknesses.

The best part? His approach isn’t proprietary or complex. It’s vanilla. It’s straightforward. And that means you can start using it today.

What aspects of this workflow are you most excited to try?
Have you experimented with running multiple AI sessions in parallel?

Share your thoughts and experiences in the comments.

I Never Planned on Becoming a Google Developer Expert

lassiecoder — Sun, 27 Apr 2025 19:43:17 +0000

But the Path Is Starting to Make Sense

Becoming a Google Developer Expert (GDE) was never on my radar, at least not in the beginning. I didn’t start contributing to the community with a title or badge in mind. I was just building things, breaking things, and sharing whatever I learned along the way. That’s still the core of what I do, but now I’ve realized something important: the things I’m already doing, and the things I want to do more intentionally, are exactly the steps that lead toward becoming a GDE.

I’m not a GDE yet. But I’ve taken the time to understand what the program is really about, and what kind of contributions it values. So if you’re like me, someone who’s active in the community and curious about leveling up, here’s what I’ve learned so far about how to get on the path.

Share What You Know – Consistently and Publicly

One of the biggest realizations I had was this: you don’t need to know everything, but you do need to share what you do know.

That can take a lot of forms:

Writing blog posts or tutorials
Making YouTube videos or live streams
Posting technical threads on X (Twitter) or LinkedIn
Creating code samples or open-source libraries

The key isn’t perfection, it’s consistency and authenticity. People want to hear how you solved something, even if you’re not the “official” expert on it. I’ve started putting more time into documenting what I learn and pushing it out publicly. Even short posts or small demos can go a long way.

Contribute to Open Source (Even in Small Ways)

Contributing to open source isn’t just about building massive libraries. It could be fixing a bug, improving documentation, creating example apps, or reviewing pull requests.

It shows that you’re engaged with the community and care about making tools better for everyone. I’ve made it a point to pick projects I actually use and contribute wherever I can, even if it’s just improving the README or opening helpful issues.

Speak at Events — Online or Offline

Public speaking used to scare the hell out of me. But it’s one of the most effective ways to share knowledge, especially when you can break down complex topics in a way that clicks for others.

You don’t need to start with a massive conference. Local meetups, developer groups, and virtual events are all great starting points. I’ve been slowly getting more comfortable with this, giving talks, joining panels, or even doing short webinars or Q&As. Every session is a chance to grow and give back.

Be Active in Developer Communities

This can be as simple as answering questions on Stack Overflow, Reddit, or Discord servers. Or offering help in Slack groups, GitHub Discussions, or even in the YouTube comments under your favorite tech channels.

When someone gets stuck, and you help unblock them, that’s real impact. It doesn’t have to be flashy to be meaningful.

Focus on a Niche or Technology You Genuinely Love

GDE’s are recognized for their expertise in a specific domain. Whether that’s Firebase, Android, Web, TensorFlow, Google Cloud, or something else, find what you’re excited about and go deep.

For me, that’s [insert your tech focus here — e.g., Firebase or Web Performance]. I try to stay up to date, build real-world projects with it, and share what I learn. Not because I have to, because I genuinely enjoy it.

Be Visible, But Stay Genuine

This is where intention matters. Visibility helps, writing, speaking, building in public, but it only works when it’s rooted in real curiosity and a desire to help others.

You can’t fake this stuff for long. And frankly, you don’t need to. If you’re solving real problems and being open about your journey, the right people will notice. That’s how most GDE’s I’ve talked to got discovered, someone noticed their consistent work and nominated them.

You Need to Be Nominated — So Build Relationships

You can’t just apply to be a GDE, someone in the program (or at Google) has to nominate you. That’s why it helps to engage with existing GDE’s, Google Developer Groups (GDGs), or Googlers themselves.

But don’t network just to “get in.” Build genuine connections. Learn from others, ask questions, collaborate, show up. I’ve found that just being part of the ecosystem naturally opens these doors over time.

Where I’m At Now

I’m still on this journey. I’m putting more effort into sharing what I know, being involved in the community, and leveling up my public contributions. Not for the title, but because I know the process itself will make me a better developer, speaker, teacher, and teammate.

If the GDE nomination comes one day, great. If not, I’ll still be doing the work that matters to me, and that’s what really counts.

If you’re thinking about aiming for GDE too, my advice is simple: start contributing in the way that feels most natural to you. Build, share, teach, connect. Keep showing up. That’s the real path, and it starts right where you are.

Project IDX + Gemini: Transforming How You Write Code

lassiecoder — Sun, 06 Apr 2025 11:52:36 +0000

Project IDX boosts your productivity with AI-assisted code suggestions from Gemini in IDX. Before you use any of the inline assistance from Gemini in IDX, make sure you add Gemini to your workspace.

Use suggested code with caution. Gemini in IDX is in preview and might give inaccurate responses. Validate all AI-assisted code and adapt it to your needs before using it in a real project.
Additionally, if you don't want your prompts used as training data to improve Gemini in IDX, don't use the chat assistant and turn off code completion in your workspace Settings.

Get code suggestions from Gemini in IDX

Gemini in IDX generates complete blocks of possible code inline. To use the Gemini inline code assistance, follow these steps:

Open your IDX workspace. If you haven't already, add Gemini to your workspace.

Go to the file or line of code you want help with and press Cmd + I (on MacOS) or Ctrl + I (on Windows/ChromeOS/Linux).

Enter a description of what you want and Gemini in IDX generates a suggestion. You can also use actions as shortcuts to guide the suggestions. For example, enter /fixError for help fixing errors in inline code.

To keep the generated code, click Accept. To paste the suggestion somewhere else or move it to a new file, select the corresponding option from the drop-down menu on the Discard button. To generate a new suggestion, click the Regenerate icon. To remove the suggestion completely, click Discard.

Tip: You can also use Interactive Chat with Gemini to instruct Gemini in natural language to perform actions directly in your workspace on your behalf, like updating code and running commands.

View Gemini commands inline

To view Gemini in IDX commands inline, for specific code, select and right-click the code you want help with.

Select Gemini from the menu and then select the action you want to perform.

Use Gemini suggested code completion

To help you write code, IDX provides AI-enabled suggested code completion that predicts and autofills code in any open file as soon as you begin to type. Suggested code completion is turned on by default.

To accept a code suggestion, press Tab. To ignore the suggestion, just keep typing.

To toggle code completion on or off, adjust your code completion settings.

Open the Settings window by clicking the gear icon or pressing Ctrl + , (on Windows/Linux/ChromeOS) or Cmd + , (on MacOS).
Search for the IDX > AI > Enable Inline Completion setting in the Workspace settings.
To turn off code completion, deselect the Enable inline code completion as you type option. You have to update code completion settings for each of your workspaces.

If you use a settings.json file, set "IDX.aI.enableInlineCompletion": false.

You can adjust this option under both the Workspace and User settings, but adjusting it in the Workspace settings ensures that the setting persists if the VM your workspace is connected to restarts. In IDX, User settings don't apply across your workspaces.

Once you've turned suggested code completion on, Gemini provides AI-assisted code suggestions. To accept a code suggestion, press Tab. To ignore the suggestion, just keep typing.

Exclude files from Gemini .aiexclude files

You can control which files from your codebase should be kept hidden from Gemini in IDX by including .aiexclude files in your project. This lets you granularly control the project context you share with Gemini.

Much like a .gitignore file, an .aiexclude file tracks files that shouldn't be shared with Gemini in IDX, including the chat experience as well as AI features that operate in the editor. An .aiexclude file operates on files at or below the directory that contains it.

Note: Files ignored by .gitignore files in your repository are automatically excluded, even if they're not listed in .aiexclude file.

Files covered by .aiexclude won't be indexed by Gemini when Codebase Indexing is enabled. Additionally, .aiexclude will affect inline assistance for covered files in the following ways:

Chat assistance: Gemini won't be able to answer questions or offer suggestions about files covered by .aiexclude.
Code completion: Suggested code completions will not be available when editing covered files.
Inline assistance: You'll be able to generate new code, but not modify existing code when editing covered files.

Other development environments such as Android Studio may also honor .aiexclude files.

How to write .aiexclude files

An .aiexclude file follows the same syntax as a .gitignore file, with the following differences:

An empty .aiexclude file blocks all files in its directory and all sub-directories. This is the same as a file that contains **/*.
.aiexclude files don't support negation (prefixing patterns with !).

Examples

Here are example .aiexclude file configurations:

Block all files named apikeys.txt at or below the directory that contains the .aiexclude file:

apikeys.txt

Block all files with the .key file extension at or below the directory that contains the .aiexclude file:

*.key

Block only the apikeys.txt file at the in the same directory as the .aiexclude, but not any subdirectories:

/apikeys.txt

Block all files in the directory my/sensitive/dir and all subdirectories. The path should be relative to the directory that contains the .aiexclude file:

my/sensitive/dir/

Wrapping Up

Gemini in Project IDX represents a significant advancement in AI-assisted development. By integrating its inline code suggestions, command access, and smart completion features into your workflow, you can dramatically reduce development time while maintaining control over which parts of your codebase the AI can access.

As you explore these capabilities, remember that Gemini is still in preview — always review its suggestions carefully and adapt them to your specific project needs. The power of combining your expertise with AI assistance creates a development experience that's both efficient and flexible.

Try implementing these features in your next Project IDX session and see how they transform your coding process!

Until next time,
lassiecoder

PS: If you found this article helpful, don't forget to share it with your dev friends and hit that follow button!

If you found my work helpful, please consider supporting it through sponsorship.

Gemini AI in Chrome DevTools

lassiecoder — Wed, 02 Apr 2025 07:38:24 +0000

Hey devCommunity! 👋

I've got something incredible to share with you today that's completely changing the game for web developers. Google has integrated Gemini AI right into Chrome DevTools, and let me tell you – it's absolutely mind-blowing!

Why This Is a Big Deal?

Remember those days when we'd spend hours debugging code or searching Stack Overflow for answers? Those days might be behind us. Imagine having an AI assistant right inside your development environment, helping you debug, optimize, and understand code in real-time. That's exactly what Google has delivered!

Here's a glimpse of some game-changing features!

Exclusive: Hidden Gems I've Discovered

Here are some lesser-known features I've found while exploring:

Code Refactoring Suggestions: Gemini can analyze your entire JavaScript file and suggest modern patterns and best practices. It's like having an automated code review!
Accessibility Insights: It can analyze your DOM structure and recommend accessibility improvements – something I haven't seen mentioned much but is incredibly useful.
Security Vulnerability Detection: While testing API calls, Gemini flagged potential security issues in my authentication logic. Talk about having your back!

Follow the official setup guide here to get started!

Pro Tips From My Experience

Use the “Ask AI” feature in the Sources panel when dealing with complex debugging scenarios. It's surprisingly good at understanding the context of your entire application.
When optimizing performance, run your code through Gemini's analysis before hitting the Performance tab. It often catches optimization opportunities that aren't visible in performance profiles.
Take advantage of the AI-powered autocomplete – it's not just for basic code completion; it understands your project's context and suggests relevant patterns.

What's Next?

I'm hearing rumors about upcoming features including:

AI-powered test generation
Automated documentation writing
Real-time code quality scoring

My Take

As someone who's been developing for years, I can say this is a genuine game-changer. It's not just another IDE feature – it's like having a senior developer, performance expert, and documentation specialist all rolled into one.

Let's Connect!
Have you tried Gemini AI in Chrome DevTools?

I'd love to hear your experiences! Drop me a line in the comments or reach out on 𝕏 @lassiecoder

Keep coding and exploring! 🚀

PS: If you find it valuable, consider sharing it with your fellow developers.

Your support means a lot, and if you'd like to contribute further, you can also sponsor my work!

Simplifying Software Architecture: Understanding MVC, MVP, and MVVM

lassiecoder — Sun, 02 Feb 2025 21:08:43 +0000

Understanding software architecture patterns is very important as applications grow more complex.

All patterns share two core components: the Model (handling data and business logic) and the View (managing user interface).

MVC uses a Controller as a traffic coordinator, allowing direct Model-View communication. MVP employs a Presenter as a strict mediator, ensuring all communication flows through it. MVVM introduces data binding through a ViewModel, automatically syncing data changes with the View.

Choose MVC for simpler web applications, MVP for highly testable systems, and MVVM for data-heavy applications with complex UIs. Companies like Stack Overflow, Google, and Apple use these patterns based on their specific needs.

In order to understand it in simplistic terms, I've covered it briefly in my newsletter scoop.

Do subscribe to my newsletter!
🔗 https://techscoop.hashnode.dev/simplifying-software-architecture-a-guide-to-mvc-mvp-and-mvvm

NPM package – community-health-files

lassiecoder — Thu, 26 Sep 2024 22:09:01 +0000

I've just built a NPM package: community-health-files

This package automates the creation and management of key files like CODE_OF_CONDUCT.md, BUG_REPORT.yml, and SECURITY.md for open-source projects. It simplifies the process of maintaining project guidelines, security policies, and codes of conduct, providing a more efficient and organized workflow.

This package helps open-source projects stay organized and compliant, saving you time and effort by handling the setup for you.

I'm always looking for feedback and contributions from the community—whether it's through improving the code, enhancing the documentation, or sharing your ideas.

🌟 Check it out, and if you find it helpful, consider adding a star on GitHub!

🔗 Link to the package on npm: https://www.npmjs.com/package/community-health-files
🔗 Link to the repo on GitHub: https://github.com/lassiecoder/community-health-files

GitHub profile README

lassiecoder — Thu, 26 Sep 2024 22:04:06 +0000

🚀 Exciting news!

I've just refreshed my GitHub profile README with my latest projects and skills! 🔥

Take a peek to see what I've been up to and witness my expertise in action:
GitHub Profile

What's its significance?
Your GitHub README functions as a dynamic portfolio, spotlighting your talents and projects for potential collaborators and connections.

Seize this chance to leave a lasting impression! 🙂

GitHub profile README

lassiecoder — Thu, 28 Mar 2024 13:53:42 +0000

🚀 Exciting news!

I've just refreshed my GitHub profile README with my latest projects and skills! 🔥

Take a peek to see what I've been up to and witness my expertise in action:
GitHub Profile

What's its significance?
Your GitHub README functions as a dynamic portfolio, spotlighting your talents and projects for potential collaborators and connections.

Seize this chance to leave a lasting impression! 🙂

npx lassiecoder – in your terminal?

lassiecoder — Tue, 12 Mar 2024 17:25:59 +0000

Preview

Create your personalized NPX introduction card

Step 1: Select a Unique Package Name
Choose a distinctive name for your package, as it will be the identifier for invoking your introduction command using npx.

Step 2: Establish a New Directory

Create a fresh directory for your package, naming it after the chosen package name.
mkdir npx-username cd npx-username

Step 3: Initialize Your Package

Initialize your project as a Node.js package using the command:
npm init -y

Step 4: Develop an Executable Script

Within your project directory, create a JavaScript file named index.js and store it in a folder named bin. This file will function as the executable script for your npx command.

Ensure to specify the bin field in package.json:
"bin": { "username": "./bin/index.js" }

Ensuring Script Execution Capability:

To enable script execution, follow these steps:

For Mac/Linux:
chmod +x bin/index.js

For Windows:
git update-index --chmod=+x bin/index.js

Step 5: Add your script to execute and display in terminal

Execute your script with the following command:
node bin/index.js

Step 6: Publish the package

Once your script runs successfully, publish the package:

1. Log in to npm:
npm adduser

2. After logging in, return to the terminal and run:
npm publish

Step 7: Execute Your NPX Command

Once the package is published, run your npx command:
npx username

Follow these steps to create your personalized NPX introduction command and share it with others!

Link to the codebase – here

Happy coding! 🚀

Embarking on a 100-Day Journey with JavaScript! 🚀

lassiecoder — Sat, 24 Feb 2024 13:13:23 +0000

Hey everyone! 👋

I'm diving headfirst into a 100-day JavaScript adventure, and I couldn't be more thrilled to share it with you all! 🎉

Over the next three months, I'll be immersing myself in everything JavaScript has to offer, from the very basics to some seriously advanced concepts. Here's a sneak peek into what's in store:

Exploring JavaScript Fundamentals:

Mastering Objects in JavaScript:

JavaScript Data Types & Operations:

Understanding Data types
Methods of primitives
Working with Numbers
Manipulating Strings
Handling Arrays & Array methods
Exploring Iterables
Map and Set data structures
WeakMap and WeakSet for memory management
Object manipulation: keys, values, entries
Destructuring assignment for efficient coding
Working with Date and time
JSON methods and toJSON for data serialization

Advanced Function Techniques in JavaScript:

Recursion and managing the stack
Leveraging Rest parameters and spread syntax
Understanding Variable scope and closure
Considerations with the old "var" keyword
Exploring the Global object
Function objects and Named Function Expressions (NFE)
Utilizing the "new Function" syntax
Scheduling tasks with setTimeout and setInterval
Applying Decorators and forwarding with call/apply
Function binding for managing context
Revisiting Arrow functions and their nuances

Advanced Object Property Configuration & Prototypal Inheritance:

Understanding Property flags and descriptors
Implementing Property getters and setters for controlled access
Delving into Prototypal inheritance and its mechanisms
Exploring F.prototype and its role in inheritance chains
Native prototypes and their usage in JavaScript
Prototype methods and handling objects without proto references

Exploring JavaScript Classes:

Introduction to Class basic syntax
Implementing Class inheritance
Defining Static properties and methods within classes
Understanding Private and protected properties and methods
Extending built-in classes for custom functionality
Class checking using "instanceof"
Utilizing Mixins for flexible composition of behavior

Handling Errors in JavaScript:

Implementing basic error handling with "try...catch"
Creating Custom errors by extending the Error object

Promises, async/await JavaScript Operations:

Introduction to callbacks
Understanding Promises and their usage
Chaining Promises for sequential operations
Error handling with Promises
Exploring the Promise API for additional functionality
Promisification for converting callback-based functions to Promise-based
Managing microtasks
Utilizing async/await for asynchronous code readability and simplicity

Generators, advanced iteration & Modules Features:

Understanding Generators for advanced iteration
Exploring async iteration and generators for asynchronous operations
Introduction to Modules and their benefits
Exporting and Importing modules for code organization and reusability
Dynamically importing modules for efficient loading and dependency management

Miscellaneous JavaScript Topics:

Utilizing Proxy and Reflect for meta-programming and interception
Running code strings dynamically with eval (caution advised)
Implementing Currying for functional programming
Understanding Reference Type in JavaScript
Working with BigInt for handling large integer values
Exploring Unicode and String internals for character encoding
Utilizing WeakRef and FinalizationRegistry for memory management and cleanup duties

Stay tuned for daily updates, challenges, and plenty of code snippets! Let's make these 100 days count! 💻✨

Feel free to share this post with fellow coders and enthusiasts. Let's spread the JavaScript love far and wide! 🚀 #100DaysOfJavaScript #CodeNewbie #JavaScriptJourney

See you in the code! 😉

Here's the link to my GitHub repository where you can find all the latest updates and progress reports.