Issue with Tags plugin installation and usage in Sanity.io Studio

7 replies
Last updated: Oct 14, 2022
I’m using the Tags plugin and having issues when trying to install and run the studio. Wondering if anyone else is having this issue or understands how to utilize an appropriate loader. Thanks!

Error in ./node_modules/@floating-ui/dom/dist/floating-ui.dom.esm.js

Module parse failed: Unexpected token (306:11)
You may need an appropriate loader to handle this file type.
AI Update

I can see you're getting a module parse error with @floating-ui/dom when using the Tags plugin. This error typically means your build tool is encountering JavaScript syntax it's not configured to handle properly.

Since Sanity Studio v3 uses Vite as its build tool, you can configure it to handle this dependency through your sanity.config.ts (or .js) file. Here are some steps to troubleshoot:

1. Configure Vite to optimize the dependency

Add a Vite configuration to your sanity.config file:

import {defineConfig} from 'sanity'

export default defineConfig({
  // ... your other config (projectId, dataset, plugins, etc.)
  
  vite: {
    optimizeDeps: {
      include: ['@floating-ui/dom']
    }
  }
})

This tells Vite to pre-bundle and optimize the @floating-ui/dom module during development.

2. Verify your Node.js version

Make sure you're using a compatible Node.js version. Studio v3 requires Node.js 18+, and Studio v4 requires Node.js 20+:

node --version

3. Clear your cache and reinstall

Sometimes build artifacts get corrupted:

rm -rf node_modules .sanity
npm install

4. Update your dependencies

Ensure you're running recent versions:

npm install sanity@latest
npm update

5. Check which tags plugin you're using

There are different tags implementations in the Sanity ecosystem. Run:

npm list | grep tags

If the Vite configuration doesn't resolve the issue, it's worth checking the plugin's GitHub repository for any reported issues or compatibility notes with your Studio version. You might also want to share your specific setup (Studio version, plugin version, and package.json) in the Sanity Community Slack where others who've encountered similar build errors can help troubleshoot.

The error about needing "an appropriate loader" is a build configuration issue rather than a code problem, so the Vite configuration approach above is the most direct way to address it.

Hey
user B
! What method did you use for installing the plugin? Can you share examples of where you're using it in your code?
Hi
user M
thanks! I used the docs for install (so “sanity install tags” within the studio) and then I’m using the tag within a document schema which I then query. I suspect it has to do with the npm install but I’ve gone through and still can’t quite track the culprit. I do know that when I remove the plugin everything is working fine though so I suppose it might be that floating-ui dependency?

project.js document schema

import { ComponentIcon } from '@sanity/icons'
import sanityClient from 'part:@sanity/base/client'

const client = sanityClient.withConfig({ apiVersion: '2021-03-25' })

import {
  orderRankField,
  orderRankOrdering,
} from '@sanity/orderable-document-list';

import { getIcon } from './project-filter'

export default {
  name: 'project',
  title: 'Project',
  type: 'document',
  icon: ComponentIcon,
  orderings: [orderRankOrdering],
  groups: [
    {
      name: 'gallery',
      title: 'Gallery'
    },
    {
      name: 'seo',
      title: 'SEO'
    }
  ],
  fields: [
    orderRankField({ type: 'project' }),
    // Title
    {
      name: 'title',
      title: 'Title',
      type: 'string',
      validation: Rule => Rule.required()
    },
    // Slug
    {
      name: 'slug',
      type: 'slug',
      options: {
        source: async doc => {
          if (!doc.client) {
            return doc.title;
          }
          const clientTitle = await client.fetch(`*[_id == "${doc.client._ref}"][0].title`)
          return `${clientTitle}-${doc.title}`;
        }
      }
    },
    // Year
    {
      name: 'year',
      title: 'Year',
      type: 'date',
      options: {
        dateFormat: 'YYYY',
        calendarTodayLabel: 'Today'
      }
    },
    // Project Type
    {
      title: 'Project Type',
      name: 'projectType',
      type: 'string',
      options: {
        layout: 'radio',
        list: [
          { title: 'Client', value: 'client' },
          { title: 'Personal', value: 'personal' },
        ]
      }
    },
    {
      name: 'client',
      type: 'reference',
      title: 'Client',
      to: [{type: 'client' }],
      hidden: ({document}) => document?.projectType != 'client'
    },
    // Tags
    {
      name: 'myTags',
      title: 'Tags',
      type: 'tags',
      options: {
        includeFromRelated: 'myTags'
      }
    },
    // Gallery
    {
      name: 'gallery',
      title: 'Gallery',
      type: 'gallery',
      group: 'gallery'
    },
    // SEO
    {
      title: 'SEO / Share Settings',
      name: 'seo',
      type: 'seo',
      group: 'seo'
    }
  ],
  preview: {
    select: {
      seoImage: 'seo.image',
      images: 'gallery.images',
      image: 'gallery.images.0',
      title: 'title',
      client: 'client.title',
      year: 'year'
    },
    prepare(selection) {
      const { seoImage, title, client, images, image, year } = selection

      return {
        media: image,
        title: title,
        subtitle: `${client ? client : ''}`
      }
    }
  }
}
I resolved with this: https://github.com/sanity-io/sanity/issues/2092#issuecomment-1017433178 Not sure if that’s the best thing to do, but it worked.
Glad you got it sorted out!
got bit by this today,
user B
should we open an issue on the plugin author repo?
workaround didn’t work for me
user D
Hi! Was your issue with the Tag plugin specifically as well?
Hi 🙂 Indeed it was
I wasn’t successful in using the workaround so I just removed the plugin. It’s a shame bc I really quite liked it but oh well

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.

Was this answer helpful?