Deno version

[antonygunawan94]

Hello,

Are there any plans regarding porting sanctuary to Deno?

Thank you

[davidchambers]

Good question, @antonygunawan94! I know of Deno, but I have not yet used it.

What changes are necessary for Sanctuary to work in that runtime, do you know?

[Avaq]

For now @antonygunawan94 can use a service that handles the CJS -> ESM translation at the CDN level: https://jspm.org/

import S from 'https://jspm.dev/sanctuary@3.1.0'

console.log (S.Just (42))
//> {
//>   "fantasy-land/equals": [Function: Just$prototype$equals],
//>   "fantasy-land/lte": [Function: Just$prototype$lte],
//>   value: 42
//> }

---

If we want to provide a custom Deno build, the fastest way would probably be to introduce a new build file in /dist which provides Sanctuary as an EcmaScript module. See https://github.com/fluture-js/Fluture/tree/master/dist (and related docs). Fluture uses Rollup to generate these distributions: https://github.com/fluture-js/Fluture/blob/master/rollup.config.dist.js. There's a small difference in that Fluture's source is written for ESM. But I'm sure there's some way to transpile the other direction (CJS -> ESM).

The more thorough way is to fix #246 by completely rewriting Sanctuary as ESM (as done for Fluture in fluture-js/Fluture#276), and using a build script to bundle dependencies into a file in /dist.

Real "native" Deno support would require that all Sancuary's dependencies are written using ESM and have their sources published somewhere, and then loaded directly via their URL instead of their NPM-package-name. This would break compatibility with NPM. The compilation approach desribed above allows for supporting both runtimes.

_{(edited to correct the tone, which seemed a little snarky upon rereading, which was not my intention)}