Skip to content

Conversation

@savetheclocktower
Copy link
Contributor

The problem

In the terminal package’s README, I've got a screenshot to demonstrate the functionality. I was inclined to do what other builtin package READMEs have done and use GitHub as an image host. But I think a lot of those tricks no longer work! Try as I might, I can't get an old-style cloud.github.com/assets URL when I upload an attachment to a GitHub issue; they're all URLs that strongly imply that they are not permanent and may expire at some point in the future. (Probably to cut down on people using GitHub as an image host.)

The next best thing is to check the screenshot into source control and reference it from the README as a relative URL; this works fine on GitHub itself. But the image was showing up as broken on the terminal package’s settings page (we show the package's README after all the settings, keybindings, and whatnot).

I dug into why this was happening and it was mostly some spaghetti in a section of atom.ui.markdown.render that doesn't have any test coverage. I have taken the cowardly path and failed to add to that test coverage, but I do think this code works better than it did before.

The fix

When you call atom.ui.markdown.render, you can specify a rootDomain (if your Markdown came from a remote URL) or a filePath (if your Markdown came from a file on disk). That function has a section that handles the possible need to transform image src values (relative src values, etc.), but that section was being skipped entirely when rootDomain was omitted. This meant that settings-view’s PackageReadmeView didn't get the benefit of image src transformation at all.

Once that was fixed, there was more to solve, including an accidental negation in a conditional, and a reference to a nonexistent variable.

We also did something a bit strange: if rootDomain was specified at all, we tried a way of resolving the image that would only work if rootDomain referred to a GitHub URL. Instead, I made it so that that tactic was only attempted if we actually saw github. in rootDomain; otherwise I treated it like an arbitrary URL and combined rootDomain and src to produce an absolute URL.

Testing

This PR is against master, but I don't have a great way of testing this until the Electron 30 bump lands — because my test package is terminal, which isn't written to be compatible with Electron 12.

I'll see if I can update one of my other packages so that the README references a screenshot that lives in the repo. Then someone can install it via GitHub and verify that way.

@savetheclocktower savetheclocktower changed the title Fix readme local resolution Fix markdown image src transformation in some usages Nov 15, 2025
savetheclocktower added a commit to savetheclocktower/pulsar-hover that referenced this pull request Nov 15, 2025
for screenshot `src`.

This should help someone verify pulsar-edit/pulsar#1375.
@savetheclocktower
Copy link
Contributor Author

OK, this should let you verify this PR:

ppm install savetheclocktower/pulsar-hover

Then open Settings -> Packages -> pulsar-hover and click on Settings. Scroll past the settings to see the README and verify that the image doesn't show up as broken.

@savetheclocktower
Copy link
Contributor Author

Meanwhile, I'll update terminal’s README so that it no longer exhibits this bug. I remembered what I'd done for pulsar-hover: once the screenshot lives in the repo, you do get a URL which you can use to refer to it in the long term. That's the approach that works better for the package registry (so it doesn't have to internalize all of this logic when parsing Markdown in README.md files!).

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

Successfully merging this pull request may close these issues.

2 participants