Feature Request: Support for Custom Path Aliases in MDX Imports

[Bethel-nz]

Currently, when using @content-collections/mdx to process MDX files, it appears that custom path aliases (configured in tsconfig.json or build tools like Webpack/Rollup, e.g., @/components) are not natively resolved within import statements inside the MDX content itself. This means imports like import { MyComponent } from '@/components/MyComponent' do not work out-of-the-box.

Desired Feature:

It would be highly beneficial if content-collections could support resolving these custom path aliases directly within MDX import statements. This would align with common development practices and improve code organization and readability.

Workaround Implemented:

I have developed a workaround to achieve this functionality. My approach involves:

1. Scanning specified directories (e.g., components, lib).
2. Building a map of desired aliases (e.g., @/components/Button) to their actual relative file paths (e.g., ./components/Button.tsx).
3. Utilizing the appender.file method within the transform function of a collection definition to explicitly include these files using their mapped aliases during the MDX compilation process.

You can review the code for my workaround here: https://gist.github.com/Bethel-nz/df59a996a1cb12bf951964cab24335d1

Discussion:

I'm opening this issue to discuss the potential for integrating native support for custom path alias resolution in MDX imports within content-collections. I believe this would be a valuable addition for many users.

I would appreciate your feedback on the necessity of this feature and any thoughts on the approach taken in my workaround. I am open to contributing a pull request to implement this functionality if it aligns with the project's goals.

Thank you for considering this feature request.

[sdorra]

Have you seen the directory function of the files appender?

Imports with mdx are very tricky, please have have a look at the following comment https://github.com/sdorra/content-collections/issues/358#issuecomment-2425671697, which describes the problem in more detail.

[Bethel-nz]

Thanks so much for the detailed breakdown of the challenges with imports in the separate MDX build process and for providing the different solutions, including the @next/mdx sample! I really appreciate you taking the time to explain the nuances.

I did see the appender.directory function but ended up developing a custom solution before fully exploring it, mainly because I wanted to handle path aliases across several directories (@/components, @/utils, etc.) consistently.

My approach uses a component-map.ts utility that scans configured directories and builds a map of aliases to file paths. Then, I use appender.file within the files option in compileMDX to make all these aliases available during the MDX compilation, like this:

// In content-collections.ts transform function
files: (appender) => {
  // COMPONENT_FILES holds the map generated by buildComponentMap
  applyComponentEntries(COMPONENT_FILES, appender.file);
},

This lets me use direct imports right inside my .mdx files, which feels quite natural when writing content:

import { MyComponent } from '@/components/MyComponent';
import { someUtil } from '@/utils/helpers';

Interestingly, this setup has been working without any hitches using Turbopack, which might be relevant given the Turborepo issues you mentioned with Solution 2.

I definitely understand the trade-offs you highlighted with this approach (Solution 3) – the potential for increased bundle sizes due to less efficient code splitting and the possibility of slower build times as the project grows.

Thanks again for your help and the excellent library!