Deno support

[zebp]

Is your feature request related to a problem? Please describe.
It would be ideal to use ts-pattern on Deno via an official third party module.

Describe the solution you'd like
Ideally a Deno module could be generated via Github Actions using Denoify or a find and replace regex on import statements to include the .ts file extension which is required with Deno. (similar to what zod does)

Describe alternatives you've considered
A fork could be maintained with Deno support and have a module on the Deno third party registry but would add complexity.

Additional context
N/A

[gvergnaud]

👋
Adding Deno support would be a nice addition. After reading this article I'm under the impression that we don't need github actions if we commit the deno_dist folder that denoify outputs, am I correct?

If you want to have a go at adding deno support and open a PR, you are more than welcome to do it :)

[garronej]

Hey @gvergnaud,
Author of denoify here,
First of all, I want to congratulate you on your work on ts-pattern it is truly remarkable. I was very impressed and even quite humbled to be honest.
So much so that I am thinking about making it a dependency of the next major of EVT.

Being able to write:

import { assert, Equals } from "tsafe";
import { Evt, P } from "evt";

type Shape = Shape.Circle | Shape.Square;

namespace Shape {

	export type Circle = {
		type: "circle";
		radius: number;
	};

	export type Square = {
		type: "square";
		sideLength: number;
	};

}

const evtShape = Evt.create<Shape>();

evtShape.attach(
    { "type": "square", "sideLength": P.select() },
    (sideLength, square) => {

	assert<Equals<typeof sideLength, number>>();
	assert<Equals<typeof square, Shape.Square>>();

    }
);

Instead of:

evtShape.attach(
    shape => shape.type !== "square" ? null : [shape.sideLenght],
    sideLength => {
	assert<Equals<typeof sideLength, number>>();
    }
);

Will truly be a killer feature for EVT! But I need ts-patern to be Denoified.

After reading this article I'm under the impression that we don't need github actions if we commit the deno_dist folder that denoify outputs, am I correct?

Yes you are right, if you don't mind tracking the deno_dist on the default branch this will work.

So, let me open a PR for you. In hope you are still interested by publishing on deno.land/x.

[gvergnaud]

Deno now supports npm packages, so you should be able to do import { match, P } from "npm:ts-pattern"

[garronej]

Hi @gvergnaud,

you should be able to do import { match, P } from "npm:ts-pattern"

For library authors that would like to make ts-pattern a dependency of their module, the npm way isn't really an option.
I think that if I were to introduce a NPM dependency to my Deno module my Deno users wouldn’t be pleased.
Plus, it would mean no retro compatibility with previous Deno release.

I think the option suggested by @lilnasy was a good one.

It's with much disappointment that I will commit to implementing my own protocol then.
Anyway, regardless, thank you for your outstanding work and the great resources you put out there.

[lilnasy]

It's with much disappointment that I will commit to implementing my own protocol then. Anyway, regardless, thank you for your outstanding work and the great resources you put out there.

There's no reason .ts extension suffixes shouldn't be adopted nor any indication that it won't be, but it might take a few weeks.

Typecript 5.0 releases in March. I don't expect ts-pattern to use it in stable sooner. Also, 5.0 would be mainlined into Deno a few weeks after, and that might become a blocker if ts-pattern uses new features (the ts-5 branch made good use of const parameters).

If I were you, I would look into making a fork of ts-pattern with floating patches for the .ts extension. I did the same here, compare/main...lilnasy:ts-pattern:main. It should only be a couple of months at most.

[lilnasy]

That said, the issue should be reopened.

[garronej]

Hi @lilnasy,
Getting it to run on Deno isn't the problem I did a fork of ts-pattern with Denoify setup that release automatically on Deno.land: https://deno.land/x/fuzzy_octo_guacamole
But I want it to use the real thing, not a fork.

Waiting isn't a problem either, I can wait, it's just that I don't think it's in the roadmap of gvergnaud to implement your approach and release on Deno.land.

[gvergnaud]

Re-opening the issue then.

[armand1m]

I'm trying to use the npm:ts-pattern way but I'm getting this some times:

2023-03-27T16:18:45.422 app[111d392f] ams [info] Download https://registry.npmjs.org/ts-pattern/-/ts-pattern-4.2.2.tgz

2023-03-27T16:18:46.438 app[111d392f] ams [info] Download https://deno.land/x/[email protected]/mod.ts

2023-03-27T16:18:46.491 app[111d392f] ams [info] error: Uncaught (in promise) ReferenceError: __DENO_NODE_GLOBAL_THIS_1679933926__ is not defined

2023-03-27T16:18:46.491 app[111d392f] ams [info] at file:///app/npm/registry.npmjs.org/ts-pattern/4.2.2/dist/index.module.js:1:18

[lilnasy]

Typescript has supported importing with .ts extensions for a few months now, but it relegates its role to just the type-checker in that case. You would need to introduce a third-party compiler/bundler.

The bundler used by ts-pattern, microbundle, depends on typescript to do the compilation. This makes it nonviable with .ts extensions.

The two options are, switching out microbundle, or introducing denoify on top of it.

I am inclined towards denoify as it would be simpler to introduce, while maintaining the same compatibility with UMD that microbundle offers.

[garronej]

Thanks @lilnasy,
I've re-openned and updated my pr: #108

[hanneswidrig]

@gvergnaud lets make this happen 💪

[alexgleason]

I'm using this on Deno 2.1 with import { match, P } from 'npm:ts-pattern' and it's working perfectly. No changes needed.

[garronej]

@alexgleason Yes, starting with Deno 2. This issue was about making it work with Deno 1.

This isue can be closed.