Consider: Deno specific support items #3226
Comments
We provide both minified and non-minified files side by side if you look at the build results from the CDN ESM PR. |
|
Yes, I see. I was refering to the language files. I have a couple of questions:
export { default as 1c } from "./languages/1c.js";
export { default as abnf } from "./languages/abnf.js";
// etc.. |
There is no need for those to be provided un-minified... they are mostly data, not code - there is often nothing to debug.
Core is just the highlighting engine,
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. |
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? |
|
In my humble opinion, I see three formats:
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
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. |
That sounds like a pretty usable solution for now.
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. |
I'm not opposed to this but before that I think at a minimum we'd need 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... |
|
I'm curious how does Deno track the broader JS world with regard to:
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. |
|
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). As curiosity, both projects (Deno and Node) are created by the same guy (Ryan Dhal). |
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)
The text was updated successfully, but these errors were encountered: