feat: add benchmark and JSDoc for once function

[umsungjun]

• Added once.bench.ts for performance comparison with lodash
• Added JSDoc to once.ts

[github-actions]

✅ All utility modules are properly registered in index.ts and package.json exports!

[github-actions]

Benchmark Results

Method	Test	Performance Comparison	hidash ops/sec	lodash@4.17.21 ops/sec
once ⚠️	src/once.bench.ts > once performance	lodash is 1.77x faster	379636.91	671933.07 🏆

Note: Higher operations per second (ops/sec) numbers are better. Each test compares hidash vs lodash implementation.

⚠️ indicates where hidash is slower than lodash.

🏆 indicates the faster implementation.

View Full Benchmark Data

{
  "files": [
    {
      "filepath": "/home/runner/work/hidash/hidash/src/once.bench.ts",
      "groups": [
        {
          "fullName": "src/once.bench.ts > once performance",
          "benchmarks": [
            {
              "id": "-1642990881_0_0",
              "name": "hidash",
              "rank": 2,
              "rme": 0.5759714992018368,
              "samples": [],
              "totalTime": 500.00143000001464,
              "min": 0.002553999999918233,
              "max": 1.4377170000000206,
              "hz": 379636.91423841415,
              "period": 0.002634095796522027,
              "mean": 0.002634095796522027,
              "variance": 0.000011373461360672291,
              "sd": 0.003372456280023848,
              "sem": 0.000007740633188592083,
              "df": 189818,
              "critical": 1.96,
              "moe": 0.000015171641049640482,
              "p75": 0.002574000000038268,
              "p99": 0.005289000000004762,
              "p995": 0.006011999999998352,
              "p999": 0.010690000000067812,
              "sampleCount": 189819,
              "median": 0.0025650000000041473
            },
            {
              "id": "-1642990881_0_1",
              "name": "lodash",
              "rank": 1,
              "rme": 0.3217519054502792,
              "samples": [],
              "totalTime": 500.00069300004066,
              "min": 0.0014319999997951527,
              "max": 0.7744959999999992,
              "hz": 671933.0687007122,
              "period": 0.0014882434673644752,
              "mean": 0.0014882434673644752,
              "variance": 0.000002005278527869162,
              "sd": 0.001416078574044944,
              "sem": 0.000002443087609175767,
              "df": 335966,
              "critical": 1.96,
              "moe": 0.0000047884517139845035,
              "p75": 0.0014619999999467836,
              "p99": 0.00187299999993229,
              "p995": 0.0035060000000157743,
              "p999": 0.009547999999995227,
              "sampleCount": 335967,
              "median": 0.0014530000000831933
            }
          ]
        }
      ]
    }
  ]
}

Last updated by GitHub Actions

[hsskey]

Just a note: feat: is typically used for actual feature development in conventional commits, though I don't see established PR conventions in this project. This looks more like performance testing and documentation work.

@yceffort-naver @yujeongJeon - thoughts on commit message conventions for the project?

[umsungjun]

@hsskey

I agree. It would be helpful to have a defined PR convention. Additionally, I think it would be beneficial to clarify the scope of test cases—whether we should include only valid input cases, or also cover edge and exception cases.

[yujeong-jeon]

thoughts on commit message conventions for the project?

@hsskey @umsungjun
We haven't discussed it yet, but we haven't used it here either because we haven't used the conventional commit internally.

While I think conventional commits can help clarify the scope of changes, we're also cautious about relying solely on prefixes like feat, chore, as it could lead to careless commit messages.
In the case of hidash, it's also common to add tests and benchmarks together with each function implementation, so we're still considering the best approach for our workflow.

If you have any suggestions or experiences to share regarding commit conventions, we'd be happy to hear them :)

[yujeong-jeon]

Thank you for all :)

[umsungjun]

@yujeong-jeon

At my current company, we don’t use prefixes like feat or chore, but we do add issue numbers at the beginning of commit messages to make it easier to track changes.

While adopting a commit convention won’t necessarily make it possible to understand an entire PR at a glance, I believe it can help contributors to hidash avoid wondering “How should I write this commit message?” It could also save time spent referencing and revising previous PRs.

So, how about trying out a simple commit convention like this:

feat: for adding new features

fix: for fixing issues without adding new features

test: when only modifying or adding test code

chore: for everything else (e.g. benchmark code, documentation)

It may seem like a small change, but it could help improve communication consistency and contribute to the overall quality of the project.

I hope this helps hidash gain more attention and grow into an even better open source project 🔥

[yceffort-naver]

We created an open-source tool called commit-helper, which adds issue numbers to the beginning of commit messages, but it seems like we haven’t applied it here yet.

I’ll go ahead and set it up now:
https://github.com/NaverPayDev/cli/tree/main/packages/commit-helper

[yceffort-naver]

I think you’re referring to conventional commits, but in our case, we’re specifically encouraging people to tag issue numbers at the start of commit messages. This way, we can easily track issues and also understand the intent behind each commit. 😊

Looks like there was some confusion since it’s missing right now. 😅