MDSvex Global Components

mdsvex.config.js

import remarkAbbr from 'remark-abbr'
import rehypeSlug from 'rehype-slug'
import rehypeAutolinkHeadings from 'rehype-autolink-headings'
import md from 'mdsvex'

export const extensions = ['.svelte.md', '.md', '.svx']

export const mdsvex = md.mdsvex({
  extensions,
  smartypants: {
    dashes: 'oldschool'
  },
  remarkPlugins: [remarkAbbr],
  rehypePlugins: [
    rehypeSlug,
    [
      rehypeAutolinkHeadings,
      {
        behavior: 'wrap'
      }
    ]
  ]
})

mdsvexGlobalComponents.js

import { join, basename, extname } from 'path'

export const defaults = {
  extensions: ['.svelte.md', '.md', '.svx'],
  dir: `$lib`,
  list: []
}

/**
 * Injects global imports in all your mdsvex files
 * Specify:
 * - the root dir (defaults to `src/lib`)
 * - the array list of components (with extension), like `['Component.svelte']`
 * - the valid extensions list as an array (defaults to `['.svelte.md', '.md', '.svx']`)
 *
 * If you want the component name to be different from the file name, you can specify an array
 * of arrays: `['Component.svelte', ['Another', 'AnotherComp.svelte'], 'ThirdComp.svelte']`
 *
 * @param {Object} options options described above
 * @returns a preprocessor suitable to plug into the `preprocess` key of the svelte config
 */
export const mdsvexGlobalComponents = (options = {}) => {
  const { extensions, dir, list } = { ...defaults, ...options }
  const extensionsRegex = new RegExp('(' + extensions.join('|').replace(/\./g, '\\.') + ')$', 'i')

  if (!list || !list.length || !Array.isArray(list)) {
    throw new Error(`"list" option must be an array and contain at least one element`)
  }

  const imports = list
    .map((entry) => {
      let name = ''
      if (Array.isArray(entry)) {
        name = entry[0]
        entry = entry[1]
      }
      const ext = extname(entry)
      const path = join(dir, entry)
      name = name || basename(entry, ext)
      return `\nimport ${name} from "${path}"`
    })
    .join('\n')

  const preprocessor = {
    script(thing) {
      const { content, filename, attributes, markup } = thing
      if (!filename.match(extensionsRegex)) {
        return { code: content }
      }
      const hasModuleContext = /^<script context="module">/.test(markup)
      const isModulePass = attributes?.context === 'module'
      const isValidPass = (hasModuleContext && isModulePass) || !hasModuleContext
      if (!isValidPass) {
        return { code: content }
      }
      return { code: `${imports}\n${content}` }
    }
  }
  return preprocessor
}

svelte.config.js

import preprocess from 'svelte-preprocess'
import { mdsvex, extensions } from './svelte-kit/mdsvex.config.js'
import { mdsvexGlobalComponents } from './svelte-kit/mdsvexGlobalComponents.js'

const globalComponents = mdsvexGlobalComponents({
  dir: `$lib/components`,
  list: ['Note.svelte', 'Youtube.svelte', ['Ref', 'RefLink.svelte']],
  extensions
})

/** @type {import('@sveltejs/kit').Config} */
const config = {
  extensions: ['.svelte', ...extensions],
  preprocess: [preprocess(), globalComponents, mdsvex],
  kit: {
    target: '#svelte',
  }
}

export default config

It's my code but it's old and I'm not using this anymore, so I'm not sure; but it seems to me like you can just use paths:

const globalComponents = mdsvexGlobalComponents({
  ...
  list: ['path/to/Note.svelte', 'otherpath/to/Youtube.svelte', ['Ref', 'thirdpath/to/RefLink.svelte']],
 ...
})

hmmm...I'll give that a try...not using anymore, though?

Is this problem still an issue for you? Got something better?

"Better" depends on specifics, there isn't a universal grading for frameworks, so I can't speak to that.

We never actually used this. I was only reviewing Svelte as part of R&D for our company, and we decided the changing JS semantics made it too troublesome to get new people onboarded. The compiler aspect is lovely, but it also means you have trouble understanding what happens to your code (Harris advocates the opposite position in his latest talk; I respectfully disagree). The build steps are also too magical, which made it difficult for us to hook into for our custom needs.

Despite personally preferring Svelte's approach, I decided on Next, which is its own bundle of issues but works better for our use case.

oh, no, I meant better for this particular problem of auto importing svelte components into mdsvex files 🤣

I am personally all in on svelte, as I did not like react, as I came from html and css and design first, so svelte feels good to me, but I feel you, esp. if a team is js centric and all :-)

But in any case, hopefully this can work for me, as I am importing at least 50 or so svelte components into every single markdown file, which is no fun to update when I add or change one! 🥵

Oh sorry, I was not very focused 😅

In retrospect your question was evident. To answer it: no, I don't know of anything better, but this should work. If it doesn't, share your repo and I'll probably be able to help!

This is overcomplicated. It’s much simpler to hard-code everything and just make it a prelude:

const mdPrelude = `
import Note from "$lib/components/Note.svelte";
import Youtube from "$lib/components/Youtube.svelte";
import Ref from "$lib/components/RefLink.svelte";
`;

const mdPreludePreprocessor = {
	script({ content, filename, attributes, markup }) {
		if (filename.endsWith(".md")) {
			const hasModuleContext = /^<script context="module">/.test(markup);
			if ((hasModuleContext && attributes?.context === "module") || !hasModuleContext) {
				return { code: mdPrelude + content };
			}
		}
		return { code: content };
	},
};

See how much easier that is to read? Now it’s obviously simple enough to just drop in your config file.

Note that I have dropped multiple file extension support, compared with the base implementation—but it’s easy to reinstate if you like.

That's a great idea! You're absolutely right that it's much easier to do it that way, kind of like using a simple tool when you don't need anything fancy.

But sometimes people need to build their lists automatically for different reasons; No one in this thread didn't think of having a hard coded string, but people want to generate it for a variety of reasons. People might want the computer to make the list because:

• They have really long lists and don't want to make mistakes typing everything
• They want to use the same code in different projects, or different sets of components (like using the same recipe in different kitchens!)
• They want to change, verify, run tests, or fix the list before using it
• They're working with lots of friends on a big project and everyone needs the same list
• ... and so on

A knife is much simpler than a mixer, but they serve different purposes. It's always good to share different ways to solve problems. Thanks for your helpful suggestion!