DEV Community: Nilesh Gadekar

[Boost]

Nilesh Gadekar — Wed, 03 Dec 2025 15:09:16 +0000

Migrate your WordPress blog to Sanity in an afternoon (open-source tool)

Nilesh Gadekar ・ Dec 2 '25

#wordpress #sanity #opensource #github

[Boost]

Nilesh Gadekar — Wed, 03 Dec 2025 05:52:28 +0000

Migrate your WordPress blog to Sanity in an afternoon (open-source tool)

Nilesh Gadekar ・ Dec 2 '25

#wordpress #sanity #opensource #github

Migrate your WordPress blog to Sanity in an afternoon (open-source tool)

Nilesh Gadekar — Tue, 02 Dec 2025 16:59:14 +0000

If you're running your blog on WordPress but building your frontend with modern stacks like Next.js, Remix, or Astro, Sanity can be a much better home for your content. Structured content, Portable Text, powerful querying, real-time collaboration… all the good stuff.

The problem: actually moving your WordPress content into Sanity is usually the painful bit.

Most guides show you how to write your own migration script from scratch. We did that work, battle-tested it on real blogs, and then open-sourced the tool so you don’t have to reinvent the wheel:

👉 Repo: https://github.com/salttechno/wp-to-sanity-migration

This post walks you through what it does and how to use it.

What this tool does for you

The WordPress to Sanity Blog Migration Tool is a Node.js-based CLI that talks to the WordPress REST API and pushes everything into Sanity in a structured way.

Out of the box, it:

✅ Migrates posts, categories, tags, and media (images)
✅ Converts WordPress HTML content to Portable Text for richer editing and rendering
✅ Preserves relationships (categories, tags, featured images)
✅ Uploads images into Sanity’s asset pipeline
✅ Is idempotent – safe to run multiple times (no duplicate docs)
✅ Ships with a ready-to-use Sanity Studio configured for the migrated content

It’s focused on blog migration first, but you can extend it to pages, custom post types, authors, etc.

Prerequisites

You’ll need:

Node.js 18+
A WordPress site with the REST API enabled (default for WP 4.7+)
A Sanity project (free tier is enough)
A Sanity API token with write access

If you can open:

https://your-site.com/wp-json/wp/v2/posts

in your browser, you’re good on the WordPress side.

Quick start: migrate your blog in a few steps

1. Clone the repo and install dependencies

git clone https://github.com/salttechno/wp-to-sanity-migration.git
cd wp-to-sanity-migration
npm install

2. Configure your `.env`

Copy the example env file:

cp .env.example .env

Then edit .env:

# WordPress Configuration
WP_API_URL=https://your-wordpress-site.com/wp-json/wp/v2

# Sanity Configuration
SANITY_PROJECT_ID=your-project-id
SANITY_DATASET=production
SANITY_TOKEN=your-write-token
SANITY_API_VERSION=2024-11-25

Tip: you’ll find your Project ID and can generate a token in sanity.io/manage under your project’s settings.

3. Test connections

Before importing anything, verify both sides are reachable:

npm run test

This checks that:

WordPress REST API is reachable
Sanity credentials and token are valid

4. Run the migration

Now the fun part:

npm run migrate

Behind the scenes, the script:

Fetches categories
Fetches tags
Fetches media (images) and uploads them to Sanity
Fetches posts and creates/updates corresponding Sanity documents, wiring up all relationships

The migration is idempotent, so you can safely re-run it while tweaking schemas or content mapping.

Browse your content in Sanity Studio

The repo also includes a preconfigured Sanity Studio in the the studio/ folder.

From the project root:

cd studio
npm install
cp .env.example .env   # add your Sanity project details
npm run dev

Open:

http://localhost:3333

You’ll see:

A Post schema with Portable Text fields
Categories and Tags linked via references
Featured images wired up as Sanity image assets

You can deploy the Studio as well:

cd studio
npm run deploy

Sanity will give you a hosted Studio URL like your-blog.sanity.studio.

How the migration works under the hood

If you’re curious (or planning to extend it), here’s the rough architecture:

wordpress-client.js

Talks to the WordPress REST API, fetches posts, categories, tags, and media.
sanity-client.js

Uses @sanity/client to create or replace documents in Sanity.
html-to-blocks.js

Converts HTML from WordPress into Portable Text blocks, so your editors aren’t stuck editing raw HTML.
transformers.js

Maps WordPress entities into Sanity document shapes: posts → post, terms → category / tag, media → image assets.
migrate.js

Orchestrates the whole process in the right order and ensures it’s safe to re-run.

This makes it easy to:

Add new content types (e.g. case studies)
Plug in custom fields
Change schema names or structures on the Sanity side

What gets migrated (and what doesn’t)

Out of the box, the tool handles:

✅ Posts

Title, slug, published date
Body content → Portable Text
Excerpt → Portable Text
Featured image
Categories & tags

✅ Categories & Tags

All your post categories and tags, with relationships preserved

✅ Media (images)

Images referenced from posts are uploaded into Sanity as proper image assets

By default, it does not migrate:

Pages
Authors
Comments
Custom post types
WordPress-specific metadata

The point is to give you a clean, production-ready baseline for blog content, not an opaque black box that tries to handle every plugin and edge case.

Extending it: pages, authors, custom post types

You can absolutely extend this for more advanced setups.

Some ideas:

Authors

Fetch authors from the WordPress API
Add an author schema (already included as an optional type)
Link authors in the post transformer

Custom post types

Create additional WordPress client functions (e.g. getCaseStudies())
Add a corresponding schema in Studio
Create a transformer and call it from the migration script

There’s even an example branch in the repo that shows how to handle a custom post type.

Common gotchas (and how to fix them)

Some issues you might hit:

1. “Cannot connect to WordPress API”

Check:

Is WP_API_URL correct?
Can you open <WP_API_URL>/posts in your browser?
Is your WP site behind auth or a firewall?

2. “Sanity connection failed”

Verify:

SANITY_PROJECT_ID matches your actual project
Token has read + write permissions
Token hasn’t been revoked or expired

3. “Invalid image, could not read metadata”

This usually means there are corrupted or weird images in your WordPress media library. The script logs these but doesn’t fail the entire migration—fix them later if needed.

4. “JavaScript heap out of memory”

For very large sites, bump Node’s memory limit:

NODE_OPTIONS="--max-old-space-size=4096" npm run migrate

Plugging into your frontend

Once your content lives in Sanity, you can query it with GROQ and render with your framework of choice.

Example GROQ query:

*[_type == "post"] | order(publishedAt desc) {
  title,
  slug,
  publishedAt,
  excerpt,
  body,
  featuredImage,
  categories[]->,
  tags[]->
}

Example React/Next.js component with Portable Text:

import { PortableText } from "@portabletext/react";

export function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <PortableText value={post.body} />
    </article>
  );
}

From here, all the usual headless/modern-stack benefits kick in:

Static generation or ISR
Custom designs per post type
Multi-channel publishing
Better performance and SEO than a typical WP theme stack

Why we open-sourced it

We originally built this tool to migrate a real production blog to Sanity, without spending days writing one-off scripts and dealing with partial imports.

Instead of leaving it as an internal script, we decided to clean it up, document it properly, and release it under the MIT license.

If you:

Are stuck on WordPress but want Sanity for content
Don’t want to maintain fragile one-off migration scripts
Prefer a starting point you can hack on

…this repo should save you a lot of time.

👉 Check it out, try it, and star it if it helps:

https://github.com/salttechno/wp-to-sanity-migration

Maintainers & support

This project is maintained by Salt Technologies, a software outsourcing company in India that builds modern web apps, headless CMS projects, and data/AI-powered platforms for clients across the globe.

🌐 Software Outsourcing Company in India – Salt Technologies

If you run into issues:

Open a GitHub issue on the repo
Share ideas for improvements (custom post types, progress UI, auth support, etc.)
Or open a PR if you’ve already solved a problem others might hit

Happy migrating 🚀

How To Make Remote & Outsourced Dev Teams Actually Work (From a Developer’s POV)

Nilesh Gadekar — Tue, 02 Dec 2025 11:57:27 +0000

Remote and outsourced dev teams are no longer “special cases” – for many companies, that is the engineering org.

But if you’ve ever worked with a team in another country or time zone, you already know the pain:

Half-baked tickets
Confusing handovers
Slack pings at weird hours
Endless “Can you clarify this?” messages

As a developer who’s worked both inside an outsourcing company and with clients’ in-house teams, I’ve seen the good, the bad, and the chaotic.

This post is for:

Devs in US/EU companies who work with offshore/outsourced teams
Devs in India/other regions who are part of those outsourced teams
Tech leads trying to make this collaboration less painful for everyone

I’m not going to talk about “cost savings” or “rates”. This is purely about how to collaborate better as engineers.

1. Treat outsourced teams as part of the engineering org, not a ticket factory

The biggest mistake I see: outsourced teams are treated like a Jira vending machine.

“Here are the tickets. Just build it.”

That kills ownership and quality.

Instead:

Share the why, not just the what.

Add a small “Context / Problem” section in tickets:
- What’s the business goal?
- What metric does this impact?
- What’s the user story behind this feature?
Invite them to tech discussions.

Even if time zones don’t align, share:
- Architecture diagrams
- ADRs (Architecture Decision Records)
- Loom videos summarizing decisions
Let them disagree.

If the remote team cannot say, “This design will cause scaling issues later,” you don’t have a partnership — you have outsourced typing.

2. Write async-friendly tickets (this alone can save days per sprint)

When you work across time zones, every “quick clarification” can cost 12–24 hours.

Good tickets are an engineering productivity tool.

A simple structure that works really well:

1. Context

Short paragraph on business goal
Links to Notion/Confluence/specs

2. Requirements

Bullet out expected behavior
Cover edge cases (empty states, error states, permissions, etc.)

3. UX/UI

Link Figma/Designs
Mention which parts are “must match exactly” vs “flexible”

4. Technical Notes (optional)

Existing APIs / DB tables / models
Performance constraints
Feature flags, logging requirements

5. Acceptance Criteria

“Given / When / Then” style works great:
- Given I am a logged-in user
- When I click “Download report”
- Then a CSV is generated and emailed within 5 minutes

If your outsourced team receives tickets like this, you’ll see:

Fewer clarifications
Fewer reworks
Better estimates

And yes, your future self will also thank you.

3. Over-communicate the “definition of done”

“Done” is one of the most overloaded words in software.

For one team, “done” = code pushed.

For another, “done” = in production, dashboards green, docs updated.

To avoid surprises with remote teams, make DoD explicit. For example:

A feature is done only when:

Code merged to main (after review)
Unit tests + basic integration tests added
Linting & formatter pass
Feature behind a flag (if needed)
Monitoring/logging added (if relevant)
Basic docs / README update
Deployed to staging / production (depending on your process)

Document this once. Link it in every sprint kickoff.

It feels “process heavy”, but it reduces arguments and friction later.

4. Use pull requests as collaboration, not just gates

When working with an outsourced team, PRs can easily turn into:

“Fix this. Change that. Why did you do this?”

Which feels like a police inspection more than a review.

Instead, try:

Ask curious questions instead of accusations
- ❌ “Why did you do it like this?”
- ✅ “Can you help me understand the trade-offs you considered here?”
Suggest, don’t dictate

Use GitHub suggestions where possible:

  - const limit = 50;
  + const limit = 100; // matches product requirement for max items/page

Review structure, not just syntax
- Does the code follow architecture guidelines?
- Are we duplicating logic?
- Are there security or performance concerns?
Time-box review cycles

Remote teams often sit blocked on reviews. Define:
- “PRs < 200 LOC → review within 24 hours”
- “Larger PRs → split or schedule a review session”

Good review culture turns outsourced devs into true teammates, not “external vendors”.

5. Respect time zones and create overlap on purpose

Healthy remote collaboration = async-first, but not async-only.

Some practical tips:

Define overlap hours clearly

Even 1–2 hours of overlap can unblock a week’s worth of work.
Use the overlap for the right things
- Sprint planning
- Architecture discussions
- “Gray area” decisions

Don’t waste overlap hours on things that could have been documented.

Be very intentional about meetings
- Share agenda in advance
- Record calls
- Summarize decisions in writing

6. Share your engineering standards openly

If you’re the client / in-house team:

Share your coding guidelines
Share folder structure patterns
Share testing philosophy
Share how you like:
- Logging
- Error handling
- Observability

If you’re the outsourced team:

Ask for these explicitly.
If they don’t exist, propose a starter version.

This avoids the situation where both teams build the same thing… differently.

7. Things I’ve seen go wrong (that you can avoid)

A few recurring anti-patterns:

“Let’s give them only the boring work.”

→ You end up with a demotivated team and low-quality code in critical but “unsexy” areas.
“We’ll fix the architecture later.”

→ Spoiler: you won’t. Once multiple teams are building on top of it, your options shrink.
Only talking to project managers, never to engineers.

→ Information gets distorted. Engineers are forced to guess.
Rotating outsourced vendors frequently.

→ You lose product context each time. You save nothing in the long run.
Treating every outsourced team as disposable.

→ The best devs don’t want to work in environments where they’re treated that way.

8. If you’re a developer inside an outsourcing company

A few tips for you too:

Act like an owner, not a contractor
- Ask about business goals
- Proactively flag risks
- Suggest simplifications
Build trust with consistency
- Hit deadlines (or communicate early if you can’t)
- Don’t surprise your client with silent delays
Invest in communication skills

Your English, writing, and clarity matter almost as much as your code.
Document more than you think you need

The next dev (maybe you in three months) will thank you.

9. Wrapping up

Remote + outsourced collaboration doesn’t have to be painful.

If you:

Share context, not just tasks
Write async-friendly tickets
Make “done” explicit
Use PRs as collaboration, not punishment
Respect time zones while creating intentional overlap

…you can turn “outsourced team” into “distributed engineering org that actually ships.”

If you’re ever exploring working with a Software Outsourcing Company in India and want teams that care about code quality, communication, and long-term product health, feel free to check us out — but regardless of who you work with, I hope this post helps you build better remote collaborations.

How to Choose the Best Headless CMS for Your Jamstack Project

Nilesh Gadekar — Fri, 06 Jan 2023 05:45:30 +0000

As a developer or business owner, you know the importance of choosing the right tools for your project. When it comes to building a Jamstack website or application, one of the key decisions you'll need to make is which headless content management system (CMS) to use.

With so many options available, it can be overwhelming to determine which CMS is the best fit for your project. Here are a few key factors to consider when evaluating headless CMS options for your Jamstack project:

Features and functionality: The first thing you'll want to consider is what features and functionality you need from your CMS. Do you need support for multiple languages? Do you need advanced content modeling capabilities? Do you need a user-friendly interface for content authors? Make a list of your must-have features and use it as a starting point for evaluating different CMS options.
API-first approach: As a Jamstack developer, you'll be relying on APIs to fetch and deliver content to your website or application. It's important to choose a CMS that has a robust, well-documented API that makes it easy to retrieve and manipulate content.
Scalability: As your website or application grows, you'll need a CMS that can scale along with it. Consider the CMS's track record for handling large amounts of traffic and data, as well as any built-in scalability features it may offer.
Pricing: Don't forget to factor in cost when evaluating CMS options. While you don't want to skimp on quality, you also don't want to overspend on a CMS that offers more features than you need. Determine your budget and look for a CMS that fits within it while still meeting your project's requirements.
Community and support: Finally, consider the level of support and community resources available for the CMS you're considering. A strong community of developers and users can be a valuable resource for troubleshooting issues and learning about new features and best practices.

So, which headless CMS is right for your Jamstack project? Here are a few popular options to consider:

Contentful: Contentful is a feature-rich CMS with a focus on flexibility and ease of use. It offers a wide range of features, including support for multiple languages, advanced content modeling, and a user-friendly interface for content authors. Its API is well-documented and easy to work with, making it a popular choice for developers.
Sanity: Sanity is a open-source CMS that is popular for its simplicity and flexibility. It offers a user-friendly interface for content authors and a powerful API for developers. Its schema-based content modeling system allows for advanced customization, making it a good fit for projects with unique content requirements.
Netlify CMS: Netlify CMS is an open-source CMS that is tightly integrated with the popular static site hosting service, Netlify. It offers a user-friendly interface for content authors and a Git-based workflow for developers. Its focus on simplicity makes it a good choice for smaller projects or teams.
Headless WordPress: While WordPress is primarily known as a traditional, monolithic CMS, it can also be used in a headless configuration. In a headless setup, WordPress serves as a backend API, providing content to your Jamstack frontend via its REST API. This allows you to take advantage of WordPress's rich feature set while still leveraging the benefits of the Jamstack architecture.

By considering these factors, you can narrow down your options and choose the best headless CMS for your Jamstack project. With the right tools in place, you'll be well on your way to building a successful website or application.

Bonus Tip: Don't forget to check out Jamrix, a leading Jamstack development agency. Our team of experts can help you choose the best CMS for your project and guide you through the development process from start to finish. Contact us today to learn mo

Streamlining My Business Website with the Jamstack: A Case Study

Nilesh Gadekar — Sat, 17 Dec 2022 12:55:57 +0000

As the owner of a software development company, I know firsthand how important it is to have a professional and user-friendly website. That's why when I decided to redesign my business website, I knew I wanted to find a platform that was fast, scalable, and secure. After doing some research, I decided to rebuild my website on the Jamstack using SvelteKit.

What is the Jamstack?

For those who may not be familiar, the Jamstack is a modern web development architecture that involves building websites and apps using JavaScript, APIs, and Markup. One of the key benefits of the Jamstack is that it allows for faster performance and lower hosting costs compared to traditional server-rendered websites.

Why I Chose the Jamstack

When I first started using WordPress for my business website, I was impressed by its flexibility and the wide range of plugins available. However, as my business grew and I started receiving more traffic, I began to experience issues with the website's speed and stability. I also found that managing and updating the website was becoming increasingly time-consuming.

That's when I started looking into alternative platforms for my business website. After considering a few options, I decided to rebuild my website on the Jamstack using SvelteKit, a new and innovative framework for building serverless web applications.

The Benefits of the Jamstack

In addition to the improved performance and lower costs, the Jamstack offers a number of other benefits that are particularly relevant for businesses.

First, the Jamstack offers improved security. Because static sites are not dynamically generated, they are less vulnerable to certain types of attacks such as SQL injection. Additionally, static sites can be served over SSL with minimal effort, which helps to protect sensitive information such as login credentials and credit card numbers.

Second, the Jamstack is highly scalable. Because static sites can be easily scaled up or down as needed, they can handle sudden spikes in traffic without breaking a sweat. This is especially important for businesses that may experience seasonal or event-related spikes in traffic.

Finally, the Jamstack is flexible and customizable. With a wide range of tools and frameworks available, it's easy to tailor your website to meet the specific needs of your business. And because static sites are pre-built, it's easy to make changes and updates without affecting the performance of the site.

My Experience with the Jamstack

I've been extremely happy with my decision to rebuild my business website on the Jamstack using SvelteKit. The framework's developer experience is top-notch, and I've found the build process to be smooth and efficient. The improved performance and lower costs have also been a major benefit, and I've received positive feedback from my website visitors about the faster loading times.

If you're considering a redesign for your business website, I highly recommend giving the Jamstack a closer look. Whether you're a small business owner or a large corporation, the benefits of the Jamstack are hard to ignore. And with a growing number of tools and frameworks available, it's never been easier to get started.

How to setup Tailwind CSS with PostCSS & Browsersync?

Nilesh Gadekar — Mon, 01 Mar 2021 18:38:54 +0000

So, you want to start using Tailwind CSS for your next HTML project but don't know how to set it up with PostCSS & Browsersync? Please read this post till the end to start using it easily.

We will see how you can use Gulp js to automate browser reload on file saving, create an optimized version of Tailwind CSS, and optimize production images.

Tailwind CSS output needs to be optimized for production use. The development version for the CSS file is almost 4MB which is not good for production websites. Read this for more details.

So, ideally, you need an editable full version of Tailwind CSS while developing the project. And you need to optimize it for production. We also need to configure the server to watch our files for changes & reload the browser automatically after updates.

We will use gulp js for the automation to enhance our workflow.

What will we achieve in the end?

Launch development environment with browser auto-refresh & browser auto-sync
Customize Tailwind CSS configuration as per your needs
Build the optimized production version of Tailwind CSS
Optimize all images for production

You can find the following code on GitHub as Tailwind CSS Boilerplate

Let's start.

Project Setup

Create a new directory and open it in VS Code.

mkdir tailwind-starter
cd tailwind-starter
code .

Install latest Tailwind CSS & dependencies.

npm install -D tailwindcss@latest postcss@latest autoprefixer@latest

Remember that Tailwind CSS requires Node.js 12.13.0 or higher.

Next, let's generate our tailwind.config.js and postcss.config.js files:

npx tailwindcss init -p

PostCSS works as our preprocessor here. It will compile our Tailwind CSS file. We will use the tailwind.config.js file for configuring our Tailwind.

The first thing we will configure is the purge settings. Add our CSS files & HTML files in an array for purge settings. These are the locations where we will be using Tailwind classes.

// tailwind.config.js
module.exports = {
    purge: ["./src/**/*.css", "./**/*.html"],
    darkMode: false, // or 'media' or 'class'
    theme: {
      extend: {},
    },
    variants: {
      extend: {},
    },
    plugins: [],
}

You can use this same file for any customization with our Tailwind CSS. Refer to this link to learn more about customization settings.

Adding CSS & HTML files

Now, let's add a CSS file first where we will inject tailwind directives.

Create an src folder in our project's root directory. Add a new file in this directory and name it styles.css. Add the following content to the newly created CSS file. To learn more about this, refer to this link

/* ./src/styles.css */
@tailwind base;
@tailwind components;

body {
    @apply bg-white text-gray-700;
}

@tailwind utilities;

Create a new folder in our project's root directory named assets. We will be using this folder for storing all assets required in the project. Within this new folder, create separate folders for css & images. The compiled version of our CSS file will be stored in this folder by gulp task.

Now, let's add our index.html in the root directory and include the compiled CSS file's path.

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <link href="/assets/css/styles.css" rel="stylesheet" />
        <title>
            Tailwind CSS Boilerplate (PostCSS + Browsersync + Gulp 4 + Imagemin)
        </title>
    </head>
    <body>
        <div class="container mx-auto py-12">
            <h1 class="text-4xl font-bold text-gray-900">
                Tailwind CSS Boilerplate (PostCSS + Browsersync + Gulp 4 +
                Imagemin)
            </h1>
            <p class="text-lg mt-4">
                Tailwind CSS boilerplate for HTML projects. Bare-bones HTML
                template with Tailwind CSS, PostCSS, Gulp, Imagemin &amp;
                Browsersync.
            </p>
        </div>
    </body>
</html>

If you open this file now in the browser, you won't see Tailwind CSS working. For that, we need to do the following tasks.

Adding Gulp & Browsersync

Next, we need to install the gulp, Browsersync & gulp-postcss plugin.

npm install -D gulp browser-sync gulp-postcss gulp-imagemin

Gulp will help us automate our workflow. Browsersync will help us in reloading the browser automatically after updating files. gulp-postcss will help us in processing our Tailwind CSS.

Now, let's create the gulpfile. In your project's root folder, create a new file and name it gulpfile.js. Open this file in the editor and add the following code:

// gulpfile.js
const { watch, series, src, dest } = require("gulp");
var browserSync = require("browser-sync").create();
var postcss = require("gulp-postcss");
const imagemin = require("gulp-imagemin");

// Task for compiling our CSS files using PostCSS
function cssTask(cb) {
    return src("./src/*.css") // read .css files from ./src/ folder
        .pipe(postcss()) // compile using postcss
        .pipe(dest("./assets/css")) // paste them in ./assets/css folder
        .pipe(browserSync.stream());
    cb();
}

// Task for minifying images
function imageminTask(cb) {
    return src("./assets/images/*")
        .pipe(imagemin())
        .pipe(dest("./assets/images"));
    cb();
}

// Serve from browserSync server
function browsersyncServe(cb) {
    browserSync.init({
        server: {
            baseDir: "./",
        },
    });
    cb();
}

function browsersyncReload(cb) {
    browserSync.reload();
    cb();
}

// Watch Files & Reload browser after tasks
function watchTask() {
    watch("./**/*.html", browsersyncReload);
    watch(["./src/*.css"], series(cssTask, browsersyncReload));
}

// Default Gulp Task
exports.default = series(cssTask, browsersyncServe, watchTask);
exports.css = cssTask;
exports.images = imageminTask;

We have defined 3 main tasks in this file for Gulp. The first task is for compiling CSS files using PostCSS. We are reading CSS files located in ./src folder, compiling them using PostCSS and then pasting compiled CSS files in ./assets/css folder.

Another task is created to launch the server from the working directory. As a default Gulp task, we have a series of tasks where we are watching .html & .css files for changes, compiling files & reloading the browser.

Defining scripts in package.json

Now, to run those gulp tasks, we will define scripts in our package.json file. We will define 3 scripts here. Check the below code for reference. I'm not adding full package.json as you don't need to change anything else in the file. Just find the scripts object in the package.json and add the following code:

// package.json
{
    // ...
    "scripts": {
        "dev": "gulp",
        "build": "NODE_ENV=production gulp css",
        "build-images": "gulp images"
    },
    // ...
}

This step completes our setup. Our project is now ready with the playground.

Using our boilerplate

From the root directory of our project, run

npm run dev

to start the development server. Now you should be able to see the project running at localhost:3000. This will watch our .html & .css files for changes. It will compile CSS if needed & reload the browser automatically.

To build for production

From the root directory of our project, run

npm run build

to create the optimized version of the Tailwind CSS file. The compiled file will be saved in the ./assets/css/ directory.

To create optimized version of images stored in ./assets/images/ directory, run npm run build-images. This will replace original images with an optimized version.

You can find the whole Tailwind CSS boilerplate on GitHub as well. You can clone it, run npm install, and get started.

If you find this useful, don't forget to star our GitHub repo. Also, I run a small AI development company in Austin, TX, USA. Do visit our company website.

DEV Community: Nilesh Gadekar

[Boost]

Migrate your WordPress blog to Sanity in an afternoon (open-source tool)

Nilesh Gadekar ・ Dec 2 '25

[Boost]

Migrate your WordPress blog to Sanity in an afternoon (open-source tool)

Nilesh Gadekar ・ Dec 2 '25

Migrate your WordPress blog to Sanity in an afternoon (open-source tool)

What this tool does for you

Prerequisites

Quick start: migrate your blog in a few steps

1. Clone the repo and install dependencies

2. Configure your .env

3. Test connections

4. Run the migration

Browse your content in Sanity Studio

How the migration works under the hood

What gets migrated (and what doesn’t)

Extending it: pages, authors, custom post types

Pages

Authors

Custom post types

Common gotchas (and how to fix them)

1. “Cannot connect to WordPress API”

2. “Sanity connection failed”

3. “Invalid image, could not read metadata”

4. “JavaScript heap out of memory”

Plugging into your frontend

Why we open-sourced it

Maintainers & support

How To Make Remote & Outsourced Dev Teams Actually Work (From a Developer’s POV)

1. Treat outsourced teams as part of the engineering org, not a ticket factory

2. Write async-friendly tickets (this alone can save days per sprint)

3. Over-communicate the “definition of done”

4. Use pull requests as collaboration, not just gates

5. Respect time zones and create overlap on purpose

6. Share your engineering standards openly

7. Things I’ve seen go wrong (that you can avoid)

8. If you’re a developer inside an outsourcing company

9. Wrapping up

How to Choose the Best Headless CMS for Your Jamstack Project

Streamlining My Business Website with the Jamstack: A Case Study

What is the Jamstack?

Why I Chose the Jamstack

The Benefits of the Jamstack

My Experience with the Jamstack

How to setup Tailwind CSS with PostCSS & Browsersync?

What will we achieve in the end?

Project Setup

Adding CSS & HTML files

Adding Gulp & Browsersync

Defining scripts in package.json

Using our boilerplate

To build for production

Thank you for reading. I hope this helps you.

2. Configure your `.env`