`calc-macos` has no description tab

[arabello]

The next-mdx-remote serialization of the package's README fails because the source markdown misses a closing <img> tag. This causes the getStaticProps routine to fail and fallback to an empty (None) package rendering nothing.

• A solution addressing the serialization failure should be investigated if we want to support the missing closing tag syntax
• The fastest mitigation is to update the original source README, but this involves the hub
• We could think about to exclude the package entirely from the build if a failure is raised at this level

[smeech]

I have access on the hub if something needs changing on the calc-macos package, if that helps.

[smeech]

If the line:

<img width="185" alt="image" src="https://user-images.githubusercontent.com/23709916/175305102-2453d39b-b7d8-45f2-8a42-9286a2ab2d25.png">

just needs a </img> on the end I can edit that in place.

I agree - it would be better if a failure of this sort prevented the merge.

[arabello]

Yes, it should just need the closing tag or the auto-closing one (/>). As a support, here the stack trace

{
  _tag: 'Left',
  left: Error: calc-macos-0.1.0: Failing to serialize readme markdown: SyntaxError: unknown: Expected corresponding JSX closing tag for <img>. (16:0)

    14 | <li parentName="ol">{`You'll see a form, type the calculation`}
    15 | <img width="185" alt="image" src="https://user-images.githubusercontent.com/23709916/175305102-2453d39b-b7d8-45f2-8a42-9286a2ab2d25.png">
  > 16 | </li>
       | ^
    17 | <li parentName="ol">{`The text will be replaced with the result`}</li>
    18 | </ol>
    19 | <h2>{`Commands`}</h2>
     ....
}

If you can patch it on the hub it would be grate, because if we are like we also solve espanso/hub#114 and the new build should trigger a re-index.

I agree - it would be better if a failure of this sort prevented the merge.

Absolutely, I'll track it on another issue though

[smeech]

Done.

[arabello]

Unfortunately, the package and the index were not updated: the logic checking for delta changes between the released and the repository packages does not take in account the single package change. The package requires a new version to be updated, otherwise we need to manually update the artifacts.

Sorry for the confusion

[smeech]

So if I submit a PR for the package, unchanged except for the version that should fix it? It's something I had considered trying, although without the </img> amendment it would have failed.
I'll get onto it.

[smeech]

Success!

Thank you!

[AucaCoyan]

Great! It is my understanding that the package calc-macos is resolved, but we don't have a solution to prevent it in the future, right?

[arabello]

we don't have a solution to prevent it in the future, right?

Correct, I opened #44 which seems to me the general approach we should take but let's discuss it. For the specific serialization issue instead we can investigate farther, but we depend on the third party lib logic

The package https://hub.espanso.org/calc-macos still has the empty v.0.1.0 but it should be solved by #44

The current version instead v0.1.1 is missing the description tab (README) even if the README string is correctly fetched. I'll update the title to track this issue

[arabello]

I find out that the issue is the lack of homepage property inside the calc-macos' manifest. If the property is missing, the hub-frontend discards the entire description tab.

The homepage URL is used to correctly renders the resources assets from Github. I might remember wrong, but I think it was required as the Github user's README may contain relative paths to assets (img, links, ...). As Github resolves those paths, we do the same to point to the Github hosted assets.

At the same time, the Package Specification states that the homepage property is optional and may points to something else rather than Github repository.

I think the hub-frontend feature was designed without taking in account this policy along with a lack of communication between the hub and hub-frontend requirements.

It would not be fair to make it mandatory if the hub does not actually require it to work properly. At the same time, the hub-frontend relies on it.

IMHO the issue is non-blocking as the package is anyway shown in the hub-frontend: I would not considered it critical or a bug, rather an improvement. I would like an opinion from other maintainers though.

I will be back if I find a better way to handle those assets, without giving up the feature and the property optionality within the hub