Consider: Deno specific support items

[joshgoebel]

For convenience for Deno developers, I recomend not to minify the code, so it's more easy to see the file and line of possible errors.
To improve the discoverability, maybe add the package in the Deno register (https://deno.land/x). It's not mandatory but it's really easy to do (it works automatically with git tags, so you don't need to do any extra work). I can help you if you want.

Originally posted by @oscarotero in #3209 (comment)

[joshgoebel]

I recomend not to minify the code, so it's more easy to see the file and line of possible errors.

We provide both minified and non-minified files side by side if you look at the build results from the CDN ESM PR.

[oscarotero]

Yes, I see. I was refering to the language files.

I have a couple of questions:

• What's the difference between core.js and highlight.js? To me, both files looks the same.
• In addition to all languages, it would be nice to have a js importing and exporting all available languages. For example:

export { default as 1c } from "./languages/1c.js";
export { default as abnf } from "./languages/abnf.js";
// etc..

[joshgoebel]

Yes, I see. I was referring to the language files.

There is no need for those to be provided un-minified... they are mostly data, not code - there is often nothing to debug.

What's the difference between core.js and highlight.js? To me, both files looks the same.

Core is just the highlighting engine, highlight.js includes ~40 popular languages as well. The naming is because the common built in languages are a great choice for a lot of users.

In addition to all languages, it would be nice to have a js importing and exporting all available languages.

We do not encourage this - for 98% of web users that's the wrong thing to do... and CDN assets is our web build - it's never been intended for use of the server.

---

This is a weird transition period (CJS/ESM). We have two builds for a reason, because they serve distinct use cases. While it is possible to use our main package client-side (via a packager) that same inverse is not expected with the web build - it has always been intended for use on client-side.

Honestly Deno should use our server-side package (non-minified, as you've expect on the server, etc), and probably could if it was ESM only, but it's not. It makes sense for us to add ESM client-side builds to the web build. If that helps Deno it's a happy accident... but making other changes to our web build exclusively for Deno seems potentially problematic.

[joshgoebel]

It's not mandatory but it's really easy to do

Who controls those packages? Does anyone make sure they are official or could someone just add us tomorrow if they felt like it? Perhaps it's keyed to GitHub namespaces?

[oscarotero]

In my humble opinion, I see three formats:

• CJS: Only for Node.
• ESM: It should work on Deno, Node (.mjs) and browsers but intended to server side.
• ESM (built and minified): It should work on Deno, Node (.mjs) and browers but intended to browser side.

Anyway, if it's problematic, don't worry. We are already using highlight.js in Deno thanks to jspm.dev CDN that converts automatically all CJS code to standard ESM to work in browser and deno. For example: https://jspm.dev/highlight.js@11.0.0

Who controls those packages? Does anyone make sure they are official or could someone just add us tomorrow if they felt like it? Perhaps it's keyed to GitHub namespaces?

Unlike npm, Deno has not a centralized place to register modules, because dependencies are just urls that you can import from anywhere. https://deno.land/x is the most popular because it was created by the oficial Deno team, but there are others like https://nest.land/. And you can even import files directly from Github (raw urls like https://raw.githubusercontent.com/highlightjs/highlight.js/main/src/highlight.js). These modules registers only work like CDN that caches the original code from Github, providing a more easy to remember url.

deno.land/x works directly with Github. Anyone can create a package, just need a Github repo to link and that's all. Every time a new tag is created, a new version is released in deno.land/x (it uses webhooks under the hood).

As an example, postcss is registered at https://deno.land/x/postcss@8.3.0. You can see the link to Github repository (postcss/postcss-deno) so this is the way to know if this module was created by the official postcss team or not.

[joshgoebel]

We are already using highlight.js in Deno thanks to jspm.dev CDN that converts automatically all CJS code to standard ESM

That sounds like a pretty usable solution for now.

I see three formats

I'm not even sure we need two long-term. I'm curious to see how the CJS/ESM thing plays out a year from now. While it doesn't make sense to add un-minified languages to a web-only build right now - if we could offer a single "one ESM to rule them all" build then it would probably make sense to include originals + minified files in that single build.

[joshgoebel]

To improve the discoverability, maybe add the package in the Deno register (https://deno.land/x).

I'm not opposed to this but before that I think at a minimum we'd need markup tests that could be run in Deno via CI - ie run our existing large markup test suite in Deno... This would be the most bang for the testing buck (short of porting the whole suite) and give a pretty high confidence that the behavior we're seeing elsewhere is the same behavior in Deno.

Just knowing the outside API works isn't very helpful since that should really be a given. On the other hand faithfully reproducing 1000s of highlighting passes is another thing entirely and tests the runtime, the parser, the regex engine, etc...

[joshgoebel]

I'm curious how does Deno track the broader JS world with regard to:

• ES2020, ES2022, etc. features
• UTF-8 /.../u regex support
• regex look-behind, etc

I'd hate to say we official support Deno only to have compatibility issues hold us back in the future. Does Deno using V8 (as Node does) just mean that magically all these things are always in lock-step? For some reason I thought they had different engines, but nope looks like they are both V8.

[oscarotero]

Deno uses V8 (like Node) but is more inlined to web standards (in fact, they are already using the Web Platform Testing, like browsers such Chrome, Firefox or Safari to test web standard features: denoland/deno#9001).
So, any feature that is supported by V8, is supported by Deno.

As curiosity, both projects (Deno and Node) are created by the same guy (Ryan Dhal).