ryasmi/rulr

📐 Validation and unit conversion errors in TypeScript at compile-time. Started in 2016. Publicised in 2020.

rulr's Issues

An in-range update of mocha is breaking the build 🚨

Version 3.4.0 of mocha just got published.

Branch	Build failing 🚨
Dependency	mocha
Current Version	3.3.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

---

Release Notes

v3.4.0

Mocha is now moving to a quicker release schedule: when non-breaking changes are merged, a release should happen that week.

This week's highlights:

• allowUncaught added to commandline as --allow-uncaught (and bugfixed)
• warning-related Node flags

🎉 Enhancements

• #2793, #2697: add --allowUncaught to Node.js (@lrowe)
• #2733: Add --no-warnings and --trace-warnings flags (@sonicdoe)

🐛 Fixes

• #2793, #2697: fix broken allowUncaught (@lrowe)

🔩 Other

• #2778: Add license report and scan status (@xizhao)
• #2794: no special case for macOS running Karma locally (@boneskull)
• #2795: reverts use of semistandard directly ([#2648]) (@boneskull)

Commits

The new version differs by 9 commits0.

• 7554b31 Add Changelog for v3.4.0
• 9f7f7ed Add --trace-warnings flag
• 92561c8 Add --no-warnings flag
• ceee976 lint test/integration/fixtures/simple-reporter.js
• dcfc094 Revert "use semistandard directly"
• 93392dd no special case for macOS running Karma locally
• 4d1d91d --allow-uncaught cli option
• fb1e083 fix allowUncaught in browser
• 4ed3fc5 Add license report and scan status

false

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two Factor Authentication for your account, set its level to "Authorization only" in your account settings. semantic-release cannot publish with the default "
Authorization and writes" level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

Ideas

• API Interface for documentation and clarity in breaking changes?
• Better documentation.
• Reduce API surface
  • Remove functions that create warnings and just return the warning instances.
  • Remove under-used functions checkRegex, checkType, checkThrow, and checkBool.
• Improve API
  • Add matches and between to go with nullable, required, and optional.
• Improve naming?
  • Replace first with sequence.
  • Replace composeRules with all?
  • Replace restrictToSchema with schema?
  • Replace restrictToCollection with collection?
  • Replace hasSchema with ...?
  • Replace restrictToKeys with ...?

Ideally I'd like the rules to read correctly in the code.

validateData(hasObjectWhere({
  x: either(hasFloat, hasNull, hasUndefined), // x either has float, has null, (or) has undefined.
  y: hasString,
  z: only([
    hasObjectWhere({
      a: hasArrayWhere(item => hasFloat),
      b: isMatching('hello'),
      c: firstly(hasInteger, isBetween(0, 100)), // c firstly has integer (that) is between 0 (and) 100.
    }),
    hasFirstAMatchingC,
  ]), // z only has object where ... (and) has first a matching c.
}));

Potential New API

Rule: <D>(data: D, path: string) => ValidationError[]
Schema: { [key: string]: Rule }
validateData: <D>(rule: Rule<D>) => (data: D, path: string[]) => D // throws ValidationErrors
hasObjectWhere: (schema: Schema) => Rule // compound/reference rule
hasArrayWhere: ((item) => Rule) => Rule // compound/reference rule
hasString: Rule<string> // scalar rule
hasInteger: Rule<number> // scalar rule
hasFloat: Rule<number> // scalar rule
hasBoolean: Rule<boolean> // scalar rule
hasNull: Rule<null> // scalar rule
hasUndefined: Rule<undefined> // scalar rule
isBetween: (min = -Infinity, max = Infinity) => Rule<number> // conditional rule
isMatching: <V>(value: V) => Rule<V> // condition rule
firstly: <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - sequential all
only: <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - parallel all
either: <V>(...rules: Rule<V>[]) => Rule<V> // composer rule - parallel some

Should decide whether required or optional is superfluous. Required is probably superfluous because undefined is not a number, but undefined is an optional number.

Might be cool if it created a type based on the validation.

An in-range update of @types/node is breaking the build 🚨

Version 7.0.7 of @types/node just got published.

Branch	Build failing 🚨
Dependency	@types/node
Current Version	7.0.6
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As @types/node is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

---

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Test ticket from Code Climate

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.

• chore(deps): update dependency eslint to v9
• chore(deps): update dependency husky to v9
• chore(deps): lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

github-actions

.github/workflows/codeql-analysis.yml

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

.github/workflows/node.yml

• actions/checkout v4
• actions/setup-node v4
• actions/checkout v4
• actions/setup-node v4
• codecov/codecov-action v4.3.0
• actions/checkout v4
• actions/setup-node v4

npm

package.json

• atob ^2.1.2
• make-error ^1.3.6
• validator ^13.0.0
• @commitlint/config-conventional 19.2.2
• @types/atob 2.1.4
• @types/btoa 1.2.5
• @types/jest 29.5.12
• @types/node 20.12.7
• @types/validator 13.11.9
• @typescript-eslint/eslint-plugin 7.7.0
• @typescript-eslint/parser 7.7.0
• btoa 1.2.1
• commitlint 19.2.2
• eslint 8.57.0
• eslint-config-prettier 9.1.0
• eslint-plugin-deprecation 2.0.0
• husky 8.0.3
• jest 29.7.0
• lint-staged 15.2.2
• microbundle 0.15.1
• prettier 3.2.5
• pretty-quick 4.0.0
• semantic-release 23.0.8
• ts-jest 29.1.2
• ts-node 10.9.2
• typescript 5.4.5

nvm

.nvmrc

• node 20

---

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

rulr breaks on v12

Please see: moltar/typescript-runtime-type-benchmarks#847

Missing repo from NPM

NPM package has no repo URLs defined.

See: https://www.npmjs.com/package/rulr

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Not running on Circle CI

Unfortunatly this error doesn't have any additionnal information. Feel free to kindly ask the author of the condition-circle plugin to add more helpful informations.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

error TS2611: 'message' is defined as a property in class 'BaseError', but is overridden here in 'ValidationError' as an accessor.

Getting the following error during build step:

node_modules/rulr/dist/errors/ValidationError.d.ts:11:9 - error TS2611: 'message' is defined as a property in class 'BaseError', but is overridden here in 'ValidationError' as an accessor.

11     get message(): string;
           ~~~~~~~


Found 1 error.

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Location: package.json
Error type: The renovate configuration file contains some invalid settings
Message: Invalid configuration option: author, Invalid configuration option: commitlint, Invalid configuration option: eslintConfig, Invalid configuration option: exports, Invalid configuration option: files, Invalid configuration option: husky, Invalid configuration option: jest, Invalid configuration option: license, Invalid configuration option: main, Invalid configuration option: module, Invalid configuration option: name, Invalid configuration option: packageRules[0].make-error, Invalid configuration option: packageRules[0].validator, Invalid configuration option: packageRules[1].@commitlint/config-conventional, Invalid configuration option: packageRules[1].@types/jest, Invalid configuration option: packageRules[1].@types/node, Invalid configuration option: packageRules[1].@types/validator, Invalid configuration option: packageRules[1].@typescript-eslint/eslint-plugin, Invalid configuration option: packageRules[1].@typescript-eslint/parser, Invalid configuration option: packageRules[1].commitlint, Invalid configuration option: packageRules[1].eslint, Invalid configuration option: packageRules[1].eslint-config-prettier, Invalid configuration option: packageRules[1].husky, Invalid configuration option: packageRules[1].jest, Invalid configuration option: packageRules[1].microbundle, Invalid configuration option: packageRules[1].prettier, Invalid configuration option: packageRules[1].pretty-quick, Invalid configuration option: packageRules[1].semantic-release, Invalid configuration option: packageRules[1].ts-jest, Invalid configuration option: packageRules[1].ts-node, Invalid configuration option: packageRules[1].typescript, Invalid configuration option: prettier, Invalid configuration option: publishConfig, Invalid configuration option: releases, Invalid configuration option: renovate, Invalid configuration option: scripts, Invalid configuration option: source, Invalid configuration option: typings, Invalid configuration option: unpkg, Invalid configuration option: version

Test ticket from Code Climate