Get help on Discord

When will custom webpack configuration feature be released?

1 replies
Last updated: Jul 1, 2021
Hi Sanity Team, i see there is some new code in the repo that allows for customizing the webpack configuration. Any ideas on when this will be released? (Or, is there a way I can install 
@sanity/server
at this latest commit? I'm not sure how to do this with a monorepo..)
AI Update

I understand you're seeing some code in a repository that references webpack configuration customization and @sanity/server, and you're wondering when it will be released or how to install from a specific commit.

First, let me clarify the current state of Sanity Studio's build tooling: Sanity Studio has used Vite (not webpack) since Studio v3 was released in January 2023. The @sanity/server package was part of the older Studio v2 architecture and is no longer actively developed.

However, I want to acknowledge that you're seeing specific code in a repository, and there could be a few scenarios here:

If you're looking at the main Sanity repository:

  • It's possible you're seeing legacy code or tooling that's maintained for backward compatibility
  • Some internal tooling or testing infrastructure might still use webpack
  • Without seeing the specific commit or file, it's hard to say exactly what you're looking at

For customizing the build configuration in modern Sanity Studio, you'll want to work with Vite configuration instead. This is done in your sanity.config.ts (or .js) file:

// sanity.config.ts
import {defineConfig} from 'sanity'

export default defineConfig({
  // Your project settings
  projectId: 'your-project-id',
  dataset: 'production',
  
  // Custom Vite configuration
  vite: {
    // Your custom Vite configuration here
    // This gets merged with Sanity's defaults
  }
})

According to the Sanity documentation on Vite, custom Vite configuration is automatically merged with Sanity's default configuration using Vite's merge logic.

Regarding installing from a specific commit in a monorepo:

If you really need to install a package from a specific GitHub commit, you can reference it in your package.json:

{
  "dependencies": {
    "sanity": "sanity-io/sanity#commit-hash"
  }
}

However, this approach has limitations with monorepos since it will try to install the entire repository, not a specific package within it.

My recommendation: Before trying to install unreleased code, I'd suggest reaching out on the Sanity Slack community or opening a GitHub issue to clarify:

  1. What specific functionality you're trying to access
  2. Whether what you're seeing is actually intended for public release
  3. What your actual use case is - there may be a better modern approach using Vite configuration

Could you share the specific GitHub URL or commit you're referencing? That would help the community provide more specific guidance on whether this is something you should be using and when it might be officially released. The Sanity team is pretty responsive on Slack and can let you know if there's a timeline for any webpack-related features you might be seeing in the codebase.

Show original thread
1 reply
All good! that --tag=custom-webpack should do the trick.My use case, by the way, is related to the split pane previews. I'm importing components from my frontend app, which is built on next.js. There are a few dependencies that will break when used outside of the context of a next app, such as 
next/link
, as well as some node stuff like 
fs
, 
net
& 
tls
. So, I need to tell webpack to resolve 
next/link
to a simple mock I'm using. Here is how I'm doing it:

const webpack = require('../.sanity-temp/node_modules/webpack');
const path = require('path');
const { merge } = require('webpack-merge');
const dotenv = require('dotenv');

const envPath = path.resolve(__dirname, '../docs/.env');

const { parsed: envVars } = dotenv.config({ path: envPath });

const modulesToTransform = [/tailwind-styled-components/];

module.exports = (config) => {
  config.module.rules = config.module.rules.map((rule) => {
    if (!rule.test || rule.test.toString() !== /(\.jsx?|\.tsx?)/.toString()) {
      return rule;
    }
    return {
      ...rule,
      exclude: (absPath) => {
        if (modulesToTransform.some((pattern) => pattern.test(absPath))) {
          return false;
        }
        if (/node_modules/.test(absPath)) return true;
        return false;
      },
    };
  });
  const custom = {
    plugins: [
      new webpack.DefinePlugin({
        CONTEXT: JSON.stringify('sanity'),
        ...Object.entries(envVars).reduce(
          (acc, [key, value]) => ({
            ...acc,
            [`process.env.${key}`]: JSON.stringify(value),
          }),
          {},
        ),
      }),
    ],
    resolve: {
      alias: {
        'next-sanity-image': path.resolve(
          __dirname,
          '../docs/src/mocks/nextSanityImage',
        ),
        'next/link': path.resolve(__dirname, '../docs/src/mocks/nextLink'),
        'next/image': path.resolve(__dirname, '../docs/src/mocks/nextImage'),
        '@sentry/node': '@sentry/browser',
        fs: path.resolve(__dirname, '../docs/.storybook/mocks/fs.mock.js'),
        net: path.resolve(__dirname, '../docs/.storybook/mocks/net.mock.js'),
        tls: path.resolve(__dirname, '../docs/.storybook/mocks/tls.mock.js'),
        react: path.resolve(__dirname, '../node_modules/react'),
        'react-dom': path.resolve(__dirname, '../node_modules/react-dom'),
        '@swell-public/docs': path.resolve(__dirname, '../docs/src/'),
      },
    },
  };

  const merged = merge(config, custom);
  return merged;
};
This is doing the trick!

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?