feat: resolve mdx imports relative to components dir

data/blog/new-features-in-v1.mdx

@@ -51,6 +51,25 @@ Please check your markdown output to verify.
 
 Some new possibilities include loading components directly in the mdx file using the import syntax and including js code which could be compiled at the build step.
 
+For example, the following jsx snippet can be used directly in an MDX file to render the page title component:
+
+```js
+import PageTitle from './PageTitle.js'
+
+;<PageTitle> Using JSX components in MDX </PageTitle>
+```
+
+import PageTitle from './PageTitle.js'
+
+<PageTitle> Using JSX components in MDX </PageTitle>
+
+The default configuration resolves all components relative to the `components` directory.
+
+**Note**:
+Components which require external image loaders would require additional esbuild configuration.
+Components which are dependent on global application state on lifecycle like the Nextjs `Link` component would also not work with this setup as each mdx file is built indepedently.
+For such cases, it is better to use component substitution.
+
 ## Layouts
 
 You can map mdx blog content to layout components by configuring the frontmatter field. For example, this post is written with the new `PostSimple` layout!

lib/mdx.js

@@ -69,6 +69,8 @@ export async function getFileBySlug(type, slug) {
   }
 
   const { code } = await bundleMDX(source, {
+    // mdx imports can be automatically source from the components directory
+    cwd: path.join(process.cwd(), 'components'),
     xdmOptions(options) {
       // this is the recommended way to add custom remark/rehype plugins:
       // The syntax might look weird, but it protects you in case we add/remove
@@ -100,6 +102,13 @@ export async function getFileBySlug(type, slug) {
       ]
       return options
     },
+    esbuildOptions: (options) => {
+      options.loader = {
+        ...options.loader,
+        '.js': 'jsx',
+      }
+      return options
+    },
   })
 
   return {