openinf/openinf-util-errors

Essential utility errors inspired by Node.js core error codes

openinf-util-errors's Issues

(JS-0331) Found explicit type declarations

Description

Explicit types where they can be easily inferred may add unnecessary verbosity for variables or parameters initialized to a number, string, or boolean

Occurrences

There are 3 occurrences of this issue in the repository.

See all occurrences on DeepSource → deepsource.io/gh/openinf/util-errors/issue/JS-0331/occurrences/

[feature request] `KeyError` runtime error

build: remove build products from repo & migrate to babel for transpilation

It is preferable not to check the compiled typescript into our repo — let's remove that javascript from here. Additionally, we should use babel for this transpilation instead of the typescript compiler. We will, however, continue using tsc for type checking and type definition generation.

[feature request] DeepScan to use ESLint over built-in rules

DeepScan has been configured to check for ESLint config instead of using its default rules. This means that it will be ready for us once ESLint is good to go here.

You've analyzed the project with ESLint, but the ESLint analysis failed by the ESLint error.

After checking the details of error and configuring ESLint correctly, please reanalyze this project.

ESLint couldn't find a configuration file. To set up a configuration file for this project, please run:

eslint --init

(JS-0059) Null comparisons without type-checking operators may not work as intended

Description

Comparing to null without a type-checking operator (=== or !==), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

Occurrences

There are 2 occurrences of this issue in the repository.

See all occurrences on DeepSource → deepsource.io/gh/openinf/util-errors/issue/JS-0059/occurrences/

[feature request] provide language-independent identifiers for errors

According to the Internationalization Best Practices for Spec Developers published by W3C Internationalization Working Group, we should be providing language-independent identifiers for errors.

It seems like the code property on each of our error instances would be the most appropriate place for this, but we are currently using constant-case identifiers (e.g., ERR_MISSING_OPTION like Node.js core) for this. Depending on how these errors are being checked at run-time, and if we want to be able to maintain interop with Node.js in the future, it may be worthwhile to use a different property for the language-independent identifier, which will most likely be composed strictly of digits.

[bug] published package is missing tests

This package is currently being flagged by Socket with a Severity: Medium issue due to a lack of tests. This is negatively impacting how its quality score is performing over there. I do not yet have a testing strategy in mind, but we should ensure that our tests are at least in line with any usage guidelines we provide to ensure that results are consistent. There are a lot of ways to wrongly check an error (e.g., instanceof is not cross-realm). Those antipattern ways should probably not be what we use in our tests since they are not very consistent and may give folks the wrong impression who refer to tests for usage examples.

---

We are being suggested to add tests and publish a new version of the package once we have done so. It is unclear whether the tests are expected to be runnable using what we have specified in dependencies or whether devDependencies would be sufficient. I want to avoid shipping packages that contain devDependencies since they frequently become outdated a lot more quickly than everything else, meaning that we would have to ship much more often. Seeing as how it would be for a reason that doesn't affect the APIs provided by the module, it would be giving consumers very little reason to upgrade to these newer versions only having these innocuous dependency updates that have no effect on production code.

Hacktoberfest checklist: prepare project for contributions by following best practices

• Add the “hacktoberfest” topic to your repository to opt-in to Hacktoberfest and indicate you’re looking for contributions.

• Apply the “hacktoberfest” label to issues you want contributors to help within your GitHub or GitLab project.

• Add a CONTRIBUTING.md file with contribution guidelines to your repository.

• Choose issues that have a well-defined scope and are self-contained.

• Adopt a code of conduct to create a greater sense of inclusion and community for contributors.

• Be ready to review pull/merge requests, accepting those that are valid by merging them, leaving an overall approving review, or by adding the “hacktoberfest-accepted” label.

• Reject any spammy requests you receive by labeling them as “spam”, and any other invalid contributions by closing them or labeling them as “invalid”.

Refs: https://hacktoberfest.com/participation/#maintainers

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• build(deps-dev): bump typescript to v5.4.5
• chore(deps): bump pnpm to v8.15.8
• chore(deps): bump actions/checkout action to v4
• chore(deps): bump github/codeql-action action to v3
• chore(deps): bump pnpm to v9
• chore(deps): bump ubuntu to v22
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

github-actions

.github/workflows/codeql-analysis.yml

• actions/checkout v3
• github/codeql-action v2
• github/codeql-action v2
• github/codeql-action v2

.github/workflows/semgrep.yml

• actions/checkout v3
• ubuntu 20.04

npm

package.json

• @types/node 20.x.x
• typescript 5.1.3
• pnpm 8.6.3

nvm

.nvmrc

• node 20

---

• Check this box to trigger a request for Renovate to run again on this repository