feat(learn): add Package Configuration article

[JakobJingleheimer]

This is an article I wrote a couple years ago. It's rather popular and addresses an issue @joyeecheung brought up at the collab summit.

I think canonical url needs to be set for SEO, so Google doesn't think it's plagiarised, but I don't know how to do that here.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Dec 18, 2024 8:23pm

[AugustinMauroy]

I think canonical url needs to be set for SEO, so Google doesn't think it's plagiarised, but I don't know how to do that here.

OH idk if we can handle that with ou current infra

[JakobJingleheimer]

I think canonical url needs to be set for SEO, so Google doesn't think it's plagiarised, but I don't know how to do that here.

OH idk if we can handle that with ou current infra

It's an html tag. But I dunno how to include that via markdown.

https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

[AugustinMauroy]

we already have that for lang

[JakobJingleheimer]

we already have that for lang

Soooo… should I add something like

canonical: https://…

[AugustinMauroy]

Soooo… should I add something like

Sadly no because canonical for lang is handle by our i18n engine.

[AugustinMauroy]

the only front matter that learn section handle is:

--- 
title: A super cool title
layout: learn
authors: github_username, another_github_username
--- 

but why not open an issue if needed

[joyeecheung]

Thanks for picking it up! I won't have time to review this until ~December, so feel free to go ahead without my approval if you want to get it out soonish. But some observations after a quick glance, which I think should be addressed given that we spent hours at the summit talking about the issues with outdated content...:

1. This doesn't reference a popular pattern that e.g. Babel uses to avoid the dual package hazard: Recommend node/default conditions instead of require/import as a solution to the dual package hazard node#52174
2. Somewhere in the beginning of the article, it should make it clear when no configuration is necessary. Generally you don't need to use the exports field at all if you just have an CJS exports (use main) and a normal package.json.
3. It's missing instructions of shipping ESM on Node.js versions >= 23 (and soon >= 22 or >= 20) while maintaining compatibility for CJS users via require(esm).
4. When surveying the exports patterns in the ecosystem I have very rarely seen the package.json specified. On the other hand, types get specified quite a lot. Maybe that's something worth teaching here too.

[JakobJingleheimer]

@joyeecheung there was talk a while ago about discouraging "main" in favour of "exports". I'm not familiar with the rationale behind it ("main" seems very okay to me without some of the drawbacks of "exports"); that's the only reason I use "exports" in the examples what aren't actually using any fanciness from exports (and "main" would be equivalent). Is that not the case? I have no preference whatsoever.

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🟢 100	🟢 100	🟢 100	🟢 91	🔗
/en/about	🟢 99	🟢 100	🟢 100	🟢 91	🔗
/en/about/previous-releases	🟢 100	🟢 100	🟢 100	🟢 92	🔗
/en/download	🟢 99	🟢 100	🟢 100	🟢 91	🔗
/en/blog	🟢 100	🟢 100	🟢 96	🟢 92	🔗

[marco-ippolito]

I have the feeling this article is not very beginner friendly and there are so many caveats and notes along the way that make it very hard to follow for someone who is not 100% into it

[JakobJingleheimer]

Thanks for the polish suggestions! I have a subsequent Learn article I need to write though, which depends on this. Could we set v1.0.0 goals for this article, and then subsequently improve it?

[JakobJingleheimer]

I haven't heard anything in a few days, so I assume there are no more requests. I'm gonna merge. If there are others, please let me know and we can iterate on the article.