Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Origin of vfile message when using remark plugin #51

Closed
aphecetche opened this issue May 30, 2021 · 4 comments
Closed

Origin of vfile message when using remark plugin #51

aphecetche opened this issue May 30, 2021 · 4 comments

Comments

@aphecetche
Copy link

I'm using a custom remarkPlugin that adds some message to a vfile under certain condition (broken link) :

const mdxFile = (route: string) => {
  // returns true or false depending on whether route is valid or not
  ...
}

const attacher = () => {
  return transformer

  function transformer(tree, file) {
    visit(tree, { type: "link" }, (node: Node) => {
      const lnode = node as LinkNode
      const route: string = lnode.url
      if (!/^http/.test(route) && !mdxFile(route)) {
        file.message(`${route} is not a valid link`)
        const title = lnode.title || ""
        lnode.title = `[BROKEN LINK]${title}`
      }
    })
  }
}

I'm later on using it like so :

const rawContent = fs.readFileSync(filePath).toString()
  const { code, frontmatter } = await bundleMDX(rawContent, {
    xdmOptions(options) {
      options.remarkPlugins = [...(options.remarkPlugins ?? []), brokenLinks]
      return options
    },
  })

It's kinda working but the output is not as helpful as I'd like as I'm loosing track of the original filePath :

> __mdx_bundler_fake_dir__/_mdx_bundler_entry_point.mdx:0:0: warning: [plugin: esbuild-xdm] /fr/recherche/equipes/sen/collisions-d-ions-lourds-et-equation-d-etat-de-la-matiere-nucleaire-2 is not a valid link
    0 │ ---
      ╵ ^

Is there a way to get the part before the warning (__mdx_bundler_fake_dir__/_mdx_bundler_entry_point.mdx:0:0 be the filePath ?

Using the cwd bundleMDX param I was able to change the __mdx_bundler_fake_dir__ part, but have no clue on how to deal with the other part (_mdx_bundler_entry_point.mdx:0:0).

Sorry if that's obvious.

  • mdx-bundler version: 4.0.0
  • node version: 14.15.3
  • npm version: 6.14.9
@Arcath
Copy link
Collaborator

Arcath commented Jun 9, 2021

_mdx_bundler_entry_point.mdx is the fake file we create in memory to hold the mdx source passed as the first option to bundleMDX.

You could replace the entry point in esbuild with the file on disk and it should give you the real path in errors.

const { code, frontmatter } = await bundleMDX('', {
  esbuildOptions(options) {
    options.entryPoints = [filePath]
    return options
  },
  xdmOptions(options) {
    options.remarkPlugins = [...(options.remarkPlugins ?? []), brokenLinks]
    return options
  },
})

This would then ignore the now empty in memory entry point and read your file straight from disk. Added bonus, you wont have to read the file contents in yourself either as esbuild will do it for you.

Arcath added a commit that referenced this issue Jun 9, 2021
… allow overwriting when using `write: true`
kentcdodds pushed a commit that referenced this issue Jun 9, 2021
* docs: change image bundling wording to make it clear that each _bundle_ needs its own output directory, closes #52

* fix: update esbuild (and dev deps)

* fix: move uvu to devDependencies

* chore: fix my website address in all contributors

* feat: add a test to check overriding `entryPoints` as described in #51, allow overwriting when using `write: true`

* docs: document replacing the entry point

* tests: swap to dirname for input path

* tests: swap to contributing and improve the match

* fix(ts): improve the typings
@Arcath
Copy link
Collaborator

Arcath commented Jun 14, 2021

@aphecetche 4.1.0 has tests for this now and supports replacing the entry point properly now.

@aphecetche
Copy link
Author

@Arcath thanks a lot. Have been diverted from this for a while, will test as soon as I can.

@aphecetche
Copy link
Author

Actually works perfectly. Thanks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants