feat(functions): adding a functions module with pipe() #6143

guy-borderless · 2024-10-24T07:38:26Z

Hi,
I'd like to suggest adding an std module for utilities related to functions.

related: #4386

There are common manipulations to functions implemented in numerous npm packages and toolbelts, and using them where appropriate greatly improves code quality. It would be handy to have these in deno_std.
I want to suggest for starters the following two:

pipe
set_arguments (currying / dependency injection)

These two scenarios have some typescript knowledge behind them and it makes sense to reach for a proper utility.

Both of these have many different implementations in terms of code and typings. In my opinion, the implementation most in line with the pragmatic spirit of the std should avoid functional programming jargon for simplicity and accessibility to beginners.

For discussion in this PR I have included two implementations (without tests) that I think would suit the deno_std

pipe has good typescript performance and small implementation. I'm also using it in several projects.

set_arguments has a very non-academic intuitive signature that I think suites nicely with the deno_std. This signature does not expect a data-last coding convention, so it doesn't leak to the rest of the code. I have also provided a more classic functional programming implementation of this called curry to contrast.

I can significantly simplify the typing definition of set_arguments if you'd like me to go ahead with preparing this PR.

Since functions are an important primitive in JS, I'm sure more utilities will be added.

kt3k · 2024-10-24T10:22:51Z

Are pipe and set_arguments common in JS ecosystem? I rarely see them in various code bases.

I personally think inline arrow functions express the operation like set_arguments better.

const myNewFunc = set_arguments(myFunc, 1, undefined, 3);
// vs
const myNewFunc = (x: number) => myFunc(1, x, 3);

guy-borderless · 2024-10-24T12:20:01Z

Are pipe and set_arguments common in JS ecosystem? I rarely see them in various code bases.

I personally think inline arrow functions express the operation like set_arguments better.
const myNewFunc = set_arguments(myFunc, 1, undefined, 3);
// vs
const myNewFunc = (x: number) => myFunc(1, x, 3);

Both curry and pipe are very common and implemented by all lodash style toolbelts (including lodash of course), as well as many specific packages. Your example works because you have the number primitive. In cases of a business object, which you may or may not control, it's much nicer to use something like curry or set_arguments.

pipe is a common pattern, for example in ETL code when you have a lot of linear transformations, it makes the code much more readable, as it prevents spaghetti.

kt3k · 2024-10-24T12:48:19Z

Your example works because you have the number primitive.

I don't understand this. Inline arrow function example should work with any parameters available in that scope. I think that has the same capability as what set_arguments (or curry) can do.

BTW do you suggest curry or set_arguments? or both?

pipe is a common pattern, for example in ETL code when you have a lot of linear transformations, it makes the code much more readable, as it prevents spaghetti.

Can you elaborate on more specific examples where pipe is better for readability? The given example looks too trivial to replace with simple function composition.

const func = pipe(Math.abs, Math.sqrt, Math.floor);
//
const func = (num: number) => Math.floor(Math.sqrt(Math.abs(num)))

guy-borderless · 2024-10-25T09:04:55Z

Your example works because you have the number primitive.

I don't understand this. Inline arrow function example should work with any parameters available in that scope. I think that has the same capability as what set_arguments (or curry) can do.

BTW do you suggest curry or set_arguments? or both?

pipe is a common pattern, for example in ETL code when you have a lot of linear transformations, it makes the code much more readable, as it prevents spaghetti.

Can you elaborate on more specific examples where pipe is better for readability? The given example looks too trivial to replace with simple function composition.
const func = pipe(Math.abs, Math.sqrt, Math.floor);
//
const func = (num: number) => Math.floor(Math.sqrt(Math.abs(num)))

I see set_arguments as just a less functional version of curry, so if we want to be more strict it's either, depending on the policy.

Yes, of course, you can create an arrow function to inject parameters:

const fnWithFirstDeps = (dataArg: Parameters<typeof fn>[2]) => fn(dependency1, dependency2, dataArg)

I think it's a common and rather generic need, so having a utility that obviates the need to create a local function for it and improves readability is handy, while also encouraging a good coding practice (dependency injection). Sometimes different parts of the code inject different dependencies, having a utility encourages doing the injection locally and not creating another function or re-using the above function which entangles concerns.

const fnWithFirstDeps = setArguments(fn, dependency1, dependency2,)

pipe is useful in data processing. You don't want to compose many functions to create a pipe as this creates long bracket scopes and isn't readable. Here is a less trivial example:

const extracted = {
  bedrooms:  pipe(
      selectOne.attributes,
      parseMatchingText("bedrooms"),
      removeLabel,
      parseNumber,
    ),
  bathrooms:  pipe(
      selectOne.attributes,
      h.parseMatchingText("bathrooms"),
      removeLabel,
      parseNumber,
    ),
}

kt3k · 2024-10-28T06:41:58Z

I'm also not a fan of these typings. curry and setArguments seem having limits in number of arguments, while inline arrow function composition doesn't have such limitation. The type of pipe function looks extremely hard to understand. I guess the type error message will be also harder to understand with pipe than plain function composition.

kt3k · 2024-10-28T06:46:19Z

(BTW while I'm personally not in favor of this, we are open for adding this package if there's enough community support to this idea.)

guy-borderless · 2024-10-29T04:59:40Z

I'm also not a fan of these typings. curry and setArguments seem having limits in number of arguments, while inline arrow function composition doesn't have such limitation. The type of pipe function looks extremely hard to understand. I guess the type error message will be also harder to understand with pipe than simpler function composition.

Typing for a number of arguments is very common and gives a good experience. As far as I can see, it's a theoretical, not a practical issue.

iuioiua · 2024-11-14T00:05:31Z

This PR and #4386, which has been open since February, have had near-zero community support. Perhaps, it'd be best to have this done as a 3rd party package and see if it evolves enough to provide a stronger argument for its addition sometime in the future.

Kacaii · 2024-11-21T01:23:20Z

Honestly pipe would help a ton. Looking forward to this one!

kt3k · 2024-11-21T07:09:00Z

@guy-borderless Can you limit this PR to pipe function? Also can you write test cases for it?

guy-borderless · 2024-11-22T05:06:33Z

@guy-borderless Can you limit this PR to pipe function? Also can you write test cases for it?

Of course! On it.

codecov · 2024-12-18T06:37:39Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.35%. Comparing base (ceca626) to head (a99eef7).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6143   +/-   ##
=======================================
  Coverage   96.35%   96.35%           
=======================================
  Files         552      554    +2     
  Lines       41937    41952   +15     
  Branches     6356     6355    -1     
=======================================
+ Hits        40407    40423   +16     
+ Misses       1490     1489    -1     
  Partials       40       40

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

guy-borderless · 2024-12-18T06:47:01Z

Per feedback, PR was limited to pipe() and tests were added.

BlackAsLight · 2024-12-18T07:02:03Z

Per feedback, PR was limited to pipe() and tests were added.

You also got to get all the tests to pass. Looks like the title isn't named right and you're missing the copyright notice in some of the files.

guy-borderless · 2024-12-18T07:15:59Z

Per feedback, PR was limited to pipe() and tests were added.

You also got to get all the tests to pass. Looks like the title isn't named right and you're missing the copyright notice in some of the files.

The PR naming issue seems to be because the functions module is new and so a scope doesn't exist for it. Added the copyright notice, thanks for mentioning it (didn't seem to cause a test to fail)

deno.json

functions/pipe.ts

BlackAsLight · 2024-12-18T10:15:39Z

The PR naming issue seems to be because the functions module is new and so a scope doesn't exist for it.

I believe a change needs to happen in .github/workflows/title.yml to recognise the functions scope. Possibly other places in .github/ as well.

deno.json

functions/mod.ts

kt3k · 2025-01-06T06:51:18Z

cc @andrewthauer Do you find this pipe function useful for your use case?

guy-borderless · 2025-01-11T04:05:16Z

cc @andrewthauer Do you find this pipe function useful for your use case?

I would note that the pipe() implementation and signature here hasn't changed since @andrewthauer's last comment and that there aren't many options for a pipe signature, and all are pretty equivalent IMO. This implementation has better typescript behavior than the typical pipe(), all thanks to @ecyrbe, but that's about it.

kt3k · 2025-01-13T09:28:16Z

functions/pipe.ts

+ * @param input The functions to be composed
+ * @returns A function composed of the input functions, from left to right
+ */
+export function pipe(): <T>(arg: T) => T;


Do we need this first overload? What is this for?

It is my habit that if an edge case has a natural interpretation I include it by default, even without a concrete use-case. This isn't a strong opinion, happy to remove this.

I would note that a scenario for this will, of course, involve .apply(). Again, I don't mind.

andrewthauer · 2025-01-19T15:01:38Z

cc @andrewthauer Do you find this pipe function useful for your use case?

Sorry just saw this. I'll pull the PR down and play around to see how well it works in regards to addressing #4386

andrewthauer · 2025-01-20T00:56:31Z

First, I will say, that the behaviour of pipe functions varies across libraries for what they call pipe. So first off I'd like to loosely classify this version as a data-last curried pipe function that works left to right.

Some libraries auto curry based on the data or function args or do not curry at all. Others distinguish the difference with something like a flow function (e.g. fs-ts's flow) vs pipe.

Ok, so here are my initial thoughts on the pipe function in it's current state:

Pipeline typing works pretty well through pipeline

const myPipe = pipe(
  (num: number) => String(num),
  (str) => Number(str),
);

myPipe(3)
^^^ accepts number returns string!

Pipeline function arguments are not inferred

This is where typing could be improved ...

const myPipe = pipe(
  (num: number) => String(num),
  (str) => Number(str),
  ^^^ Ideally this would be inferred as a string
);

Does not support for multiple arguments in first function

Not sure this is a show stopper, but it would be nice to support multiple arguments in the first function. The fs-ts flow function supports this which is nice.

const myPipe = pipe(
  (a: number, b: number) => a + b,
  (str) => Number(str),
);

myPipe2(3, 2);
        ^^^^ expected 1 args but provided 2

In general this is a good start with initial testing, but could have improved typing imo (fs-ts does a good job here), If I need a quick pipe and didn't already have another functional library pulled in I might make use of it. That said, without a builtin curry/purry function it would likely be a bit verbose to define a pipeline of functions that have multiple arguments (non unary arity). Although this is perhaps not a fault of the pipe function itself. However, the lack of a curry function makes it less useful from a functional perspective imo.

guy-borderless · 2025-01-20T05:59:25Z

Just mentioning that function arguments should be inferred in this implementation. Checking when near a computer

…

On Mon, Jan 20, 2025, 07:56 Andrew Thauer ***@***.***> wrote: First, I will say, that the behaviour of pipe functions varies across libraries for what they call pipe. So first off I'd like to loosely classify this version as a data-last curried pipe function that works left to right. Some libraries auto curry based on the data or function args or do not curry at all. Others distinguish the difference with something like a flow function (e.g. fs-ts's flow <https://gcanti.github.io/fp-ts/modules/function.ts.html#flow>) vs pipe <https://gcanti.github.io/fp-ts/modules/function.ts.html#pipe>. Ok, so here are my initial thoughts on the pipe function in it's current state: *Pipeline typing works pretty well through pipeline* const myPipe = pipe( (num: number) => String(num), (str) => Number(str),); myPipe(3)^^^ accepts number returns string! *Pipeline function arguments are not inferred* This is where typing could be improved ... const myPipe = pipe( (num: number) => String(num), (str) => Number(str), ^^^ Ideally this would be inferred as a string); *Does not support for multiple arguments in first function* Not sure this is a show stopper, but it would be nice to support multiple arguments in the first function. The fs-ts flow <https://gcanti.github.io/fp-ts/modules/function.ts.html#flow> function supports this which is nice. const myPipe = pipe( (a: number, b: number) => a + b, (str) => Number(str),); myPipe2(3, 2); ^^^^ expected 1 args but provided 2 In general this is a good start with initial testing, but could have improved typing imo (fs-ts does a good job here), If I need a quick pipe and didn't already have another functional library pulled in I might make use of it. That said, without a builtin curry/purry function it would likely be a bit verbose to define a pipeline of functions that have multiple arguments (non unary arity). Although this is perhaps not a fault of the pipe function itself. However, the lack of a curry function makes it less unseful from a functional perspective imo. — Reply to this email directly, view it on GitHub <#6143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AX35W655K5SWMCER4ZVKDTD2LRCVLAVCNFSM6AAAAABQQN6GY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBRGEYTSNZQG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

guy-borderless · 2025-01-20T12:39:13Z

Just mentioning that function arguments should be inferred in this implementation. Checking when near a computer
…
On Mon, Jan 20, 2025, 07:56 Andrew Thauer @.> wrote: First, I will say, that the behaviour of pipe functions varies across libraries for what they call pipe. So first off I'd like to loosely classify this version as a data-last curried pipe function that works left to right. Some libraries auto curry based on the data or function args or do not curry at all. Others distinguish the difference with something like a flow function (e.g. fs-ts's flow https://gcanti.github.io/fp-ts/modules/function.ts.html#flow) vs pipe https://gcanti.github.io/fp-ts/modules/function.ts.html#pipe. Ok, so here are my initial thoughts on the pipe function in it's current state: Pipeline typing works pretty well through pipeline const myPipe = pipe( (num: number) => String(num), (str) => Number(str),); myPipe(3)^^^ accepts number returns string! Pipeline function arguments are not inferred This is where typing could be improved ... const myPipe = pipe( (num: number) => String(num), (str) => Number(str), ^^^ Ideally this would be inferred as a string); Does not support for multiple arguments in first function Not sure this is a show stopper, but it would be nice to support multiple arguments in the first function. The fs-ts flow https://gcanti.github.io/fp-ts/modules/function.ts.html#flow function supports this which is nice. const myPipe = pipe( (a: number, b: number) => a + b, (str) => Number(str),); myPipe2(3, 2); ^^^^ expected 1 args but provided 2 In general this is a good start with initial testing, but could have improved typing imo (fs-ts does a good job here), If I need a quick pipe and didn't already have another functional library pulled in I might make use of it. That said, without a builtin curry/purry function it would likely be a bit verbose to define a pipeline of functions that have multiple arguments (non unary arity). Although this is perhaps not a fault of the pipe function itself. However, the lack of a curry function makes it less unseful from a functional perspective imo. — Reply to this email directly, view it on GitHub <#6143 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX35W655K5SWMCER4ZVKDTD2LRCVLAVCNFSM6AAAAABQQN6GY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBRGEYTSNZQG4 . You are receiving this because you were mentioned.Message ID: @.>

First, I will say, that the behaviour of pipe functions varies across libraries for what they call pipe. So first off I'd like to loosely classify this version as a data-last curried pipe function that works left to right.

Some libraries auto curry based on the data or function args or do not curry at all. Others distinguish the difference with something like a flow function (e.g. fs-ts's flow) vs pipe.

Ok, so here are my initial thoughts on the pipe function in it's current state:

Pipeline typing works pretty well through pipeline
const myPipe = pipe(
  (num: number) => String(num),
  (str) => Number(str),
);

myPipe(3)
^^^ accepts number returns string!
Pipeline function arguments are not inferred

This is where typing could be improved ...
const myPipe = pipe(
  (num: number) => String(num),
  (str) => Number(str),
  ^^^ Ideally this would be inferred as a string
);
Does not support for multiple arguments in first function

Not sure this is a show stopper, but it would be nice to support multiple arguments in the first function. The fs-ts flow function supports this which is nice.
const myPipe = pipe(
  (a: number, b: number) => a + b,
  (str) => Number(str),
);

myPipe2(3, 2);
        ^^^^ expected 1 args but provided 2                
In general this is a good start with initial testing, but could have improved typing imo (fs-ts does a good job here), If I need a quick pipe and didn't already have another functional library pulled in I might make use of it. That said, without a builtin curry/purry function it would likely be a bit verbose to define a pipeline of functions that have multiple arguments (non unary arity). Although this is perhaps not a fault of the pipe function itself. However, the lack of a curry function makes it less useful from a functional perspective imo.
andrewthauer

Andrew, thanks for your feedback. Initially, I considered requiring all pipe functions to be unary, even though it’s unnecessary for the first one, to simplify reordering functions within the pipe if the need arise. upon reflection and given deno-std’s unopinionated approach, this restriction does feel unnecessary, so I now removed it.

I’ve added argument typings for up to 7 pipe functions and can extend it further if needed.

While I find value in using this implementation of pipe without currying, I agree that including a curry function would be very useful. It would naturally complement pipe and enhance flexibility in the future.

kt3k · 2025-01-21T04:20:54Z

@guy-borderless @andrewthauer Do you happen to know the usage of this type of utils (such as ramda, fp-ts, etc) in major OSS projects?

guy-borderless · 2025-01-21T08:36:32Z

@guy-borderless @andrewthauer Do you happen to know the usage of this type of utils (such as ramda, fp-ts, etc) in major OSS projects?

an example from sqltyper (163 ☆)

export function isOperatorCommutative(name: string): boolean {
  return pipe(
    findOperator(name),
    Option.map((op) => op.commutative || false),
    Option.getOrElse<boolean>(() => false)
  )
}

gotenberg-js-client (103☆) recommends:

import { pipe, gotenberg, convert, html, please } from 'gotenberg-js-client'

const toPDF = pipe(
  gotenberg('http://localhost:3000'),
  convert,
  html,
  please
)

And a project called setup-macromamba (108☆) does this

export const getMicromambaUrl = (micromambaSource: MicromambaSourceType) => {
  return pipe(
    micromambaSource,
    match(
      (version) => getMicromambaUrlFromVersion(getCondaArch(), version),
      (url) => url
    )
  )
}

I would note that pipe() will probably mostly be used for concrete business flows, while GitHub projects with many stars are mostly foundational.

kt3k · 2025-01-24T12:34:07Z

@guy-borderless
I'd appreciate your efforts, but we decided not to accept this PR mainly because:

The core team is against this change, and there's no supporting opinion from there
The community reaction to this PR looks very small (especially compared with the case of collections package that had large feedback from the community. See std / collections #978 Proposal: std/collections - first part #993)
The usages in the ecosystem looks too small

For the above reasons, we don't think it's reasonable to add this to std.

I recommend you'd publish this as a 3rd party package. If that package gets popularity in the community, then we can revisit this suggestion. Thanks for your efforts anyway.

guy-borderless · 2025-01-25T06:06:24Z

@guy-borderless I'd appreciate your efforts, but we decided not to accept this PR mainly because:
* The core team is against this change, and there's no supporting opinion from there

* The community reaction to this PR looks very small (especially compared with the case of `collections` package that had large feedback from the community. See [std / collections #978](https://github.com/denoland/std/pull/978) [Proposal: std/collections - first part #993](https://github.com/denoland/std/pull/993))

* The usages in the ecosystem looks too small
For the above reasons, we don't think it's reasonable to add this to std.

I recommend you'd publish this as a 3rd party package. If that package gets popularity in the community, then we can revisit this suggestion. Thanks for your efforts anyway.

No worries, I hope that eventually there will be more of a demand to include something like a functions module. I'll publish something to JSR and post here for future reference.

andrewthauer · 2025-01-25T14:56:03Z

@kt3k, I can definitely empathize with having a defined line of what should be part of std and what should not. I am curious if there is a possibility to expand on some of the arguments against adding this (especially from the core team).

I presume this is might be related to the functional style in some way, but it would be appreciated if you could expand on some more concrete reasons so that future suggestions of adding things like pipe have this context. This may help folks look for other designs that better align with these reasons.

If this is purely based on not having enough interest that's fine and makes sense. I just want to see if there are perhaps other reasons to consider.

guy-borderless · 2025-01-25T18:07:46Z

@kt3k, I can definitely empathize with having a defined line of what should be part of std and what should not. I am curious if there is a possibility to expand on some of the arguments against adding this (especially from the core team).

I presume this is might be related to the functional style in some way, but it would be appreciated if you could expand on some more concrete reasons so that future suggestions of adding things like pipe have this context. This may help folks look for other designs that better align with these reasons.

If this is purely based on not having enough interest that's fine and makes sense. I just want to see if there are perhaps other reasons to consider.

I would like to say that in my opinion having such patterns, with good typings, available in std can greatly improve the code quality of deno projects.

For example, using pipe() with its linear constraint, where appropriate, produces code that is much easier to reason about. In my opinion, such opportunities arise quite often and use of patterns should be encouraged.

I would also note that patterns like dependency injection, via some form of a curry function, can greatly improve code quality and are often hacked in a sub-optimal way.

There are opportunities to provide good value via giving utilities for working with functions, and many toolbelts contain them.

functions-module

3d67ed4

guy-borderless requested a review from kt3k as a code owner October 24, 2024 07:38

kt3k added the feedback welcome We want community's feedback on this issue or PR label Oct 24, 2024

limit pr to pipe() and adding tests

3a08d69

guy-borderless force-pushed the functions-module branch from c7df99b to 3a08d69 Compare December 18, 2024 06:39

guy-borderless changed the title ~~functions-module~~ feat(functions): adding a functions module with pipe() Dec 18, 2024

adding copyright notice

9fc723a

guy-borderless force-pushed the functions-module branch from bd18d57 to 9fc723a Compare December 18, 2024 07:17

BlackAsLight reviewed Dec 18, 2024

View reviewed changes

deno.json Outdated Show resolved Hide resolved

BlackAsLight reviewed Dec 18, 2024

View reviewed changes

functions/pipe.ts Show resolved Hide resolved

kt3k reviewed Dec 19, 2024

View reviewed changes

deno.json Outdated Show resolved Hide resolved

kt3k reviewed Dec 19, 2024

View reviewed changes

functions/mod.ts Outdated Show resolved Hide resolved

kt3k mentioned this pull request Dec 19, 2024

chore: update title check CI #6279

Merged

kt3k changed the title ~~feat(functions): adding a functions module with pipe()~~ feat(functions): adding a functions module with pipe()_ Dec 19, 2024

guy-borderless added 3 commits December 30, 2024 14:59

adding the functions module to import_map.json

0f81c00

Merge remote-tracking branch 'denoland/main' into functions-module

f080ba7

:types lint fix

df3f242

guy-borderless force-pushed the functions-module branch from bc0f426 to df3f242 Compare January 1, 2025 07:22

jsdoc code examples & typings lint fix

e03206b

guy-borderless force-pushed the functions-module branch from d54ec2e to e03206b Compare January 1, 2025 07:56

BlackAsLight reviewed Jan 2, 2025

View reviewed changes

functions/mod.ts Outdated Show resolved Hide resolved

guy-borderless and others added 5 commits January 2, 2025 13:00

fixing export to wildcard

d388d3b

removing imports field

a943aeb

Merge branch 'denoland:main' into functions-module

7d706f8

new copyright line phrasing

8ba6add

Merge branch 'main' into functions-module

8bedf0b

Merge branch 'main' into functions-module

11f3a3a

kt3k reviewed Jan 13, 2025

View reviewed changes

argument typing of pipe

aa42c90

Merge branch 'main' into functions-module

a99eef7

kt3k closed this Jan 24, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(functions): adding a functions module with pipe() #6143

feat(functions): adding a functions module with pipe() #6143

guy-borderless commented Oct 24, 2024 •

edited

Loading

kt3k commented Oct 24, 2024

guy-borderless commented Oct 24, 2024

kt3k commented Oct 24, 2024

guy-borderless commented Oct 25, 2024 •

edited

Loading

kt3k commented Oct 28, 2024 •

edited

Loading

kt3k commented Oct 28, 2024 •

edited

Loading

guy-borderless commented Oct 29, 2024

iuioiua commented Nov 14, 2024 •

edited

Loading

Kacaii commented Nov 21, 2024

kt3k commented Nov 21, 2024

guy-borderless commented Nov 22, 2024

codecov bot commented Dec 18, 2024 •

edited

Loading

guy-borderless commented Dec 18, 2024

BlackAsLight commented Dec 18, 2024

guy-borderless commented Dec 18, 2024

BlackAsLight commented Dec 18, 2024

kt3k commented Jan 6, 2025

guy-borderless commented Jan 11, 2025

kt3k Jan 13, 2025

guy-borderless Jan 13, 2025

guy-borderless Jan 13, 2025

andrewthauer commented Jan 19, 2025

andrewthauer commented Jan 20, 2025 •

edited

Loading

guy-borderless commented Jan 20, 2025 via email

guy-borderless commented Jan 20, 2025

kt3k commented Jan 21, 2025

guy-borderless commented Jan 21, 2025

kt3k commented Jan 24, 2025

guy-borderless commented Jan 25, 2025

andrewthauer commented Jan 25, 2025 •

edited

Loading

guy-borderless commented Jan 25, 2025 •

edited

Loading

feat(functions): adding a functions module with pipe() #6143

feat(functions): adding a functions module with pipe() #6143

Conversation

guy-borderless commented Oct 24, 2024 • edited Loading

kt3k commented Oct 24, 2024

guy-borderless commented Oct 24, 2024

kt3k commented Oct 24, 2024

guy-borderless commented Oct 25, 2024 • edited Loading

kt3k commented Oct 28, 2024 • edited Loading

kt3k commented Oct 28, 2024 • edited Loading

guy-borderless commented Oct 29, 2024

iuioiua commented Nov 14, 2024 • edited Loading

Kacaii commented Nov 21, 2024

kt3k commented Nov 21, 2024

guy-borderless commented Nov 22, 2024

codecov bot commented Dec 18, 2024 • edited Loading

Codecov Report

guy-borderless commented Dec 18, 2024

BlackAsLight commented Dec 18, 2024

guy-borderless commented Dec 18, 2024

BlackAsLight commented Dec 18, 2024

kt3k commented Jan 6, 2025

guy-borderless commented Jan 11, 2025

kt3k Jan 13, 2025

Choose a reason for hiding this comment

guy-borderless Jan 13, 2025

Choose a reason for hiding this comment

guy-borderless Jan 13, 2025

Choose a reason for hiding this comment

andrewthauer commented Jan 19, 2025

andrewthauer commented Jan 20, 2025 • edited Loading

guy-borderless commented Jan 20, 2025 via email

guy-borderless commented Jan 20, 2025

kt3k commented Jan 21, 2025

guy-borderless commented Jan 21, 2025

kt3k commented Jan 24, 2025

guy-borderless commented Jan 25, 2025

andrewthauer commented Jan 25, 2025 • edited Loading

guy-borderless commented Jan 25, 2025 • edited Loading

guy-borderless commented Oct 24, 2024 •

edited

Loading

guy-borderless commented Oct 25, 2024 •

edited

Loading

kt3k commented Oct 28, 2024 •

edited

Loading

kt3k commented Oct 28, 2024 •

edited

Loading

iuioiua commented Nov 14, 2024 •

edited

Loading

codecov bot commented Dec 18, 2024 •

edited

Loading

andrewthauer commented Jan 20, 2025 •

edited

Loading

andrewthauer commented Jan 25, 2025 •

edited

Loading

guy-borderless commented Jan 25, 2025 •

edited

Loading