It's convenient to be able to use this auxiliary type in one's own code like so:

function MyComponent({ children }: PropsWithChildren) {
  return ...
}

without having to append <{}> to PropsWithChildren.

Please fill in this template.

• [x] Use a meaningful title for the pull request. Include the name of the package modified.
• [x] Test the change in your own code. (Compile and run.)
• [x] Add or edit tests to reflect the change. (Run with npm test.)
• [x] Follow the advice from the readme.
• [x] Avoid common mistakes.
• [x] Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If changing an existing definition:

• [ ] Provide a URL to documentation or source code which provides context for the suggested changes: <<url here>>
• [ ] If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• [ ] Include tests for your changes
• [ ] If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

I gave you my use case. I refuted the stupid “empty props are not props” argument. The idea that adding a default type parameter hurts readability in any way is absurd on its face. There are plenty of defaulted type parameters throughout the typings already and nobody is complaining about them making the code unreadable. Sorry for the “drive-by PR”, whatever that means. I guess PRs have to make lots of changes to be worthy of consideration?

Any chance this can get merged?

@radiantly I've published a copy of the library with this patch here.

The main startup delay seems to come from require()-ing all the dependencies.

time-require reports around 10 seconds worth of require() calls on my current system.

Main culprits, according to that tool are:

• babel - this might just be specific to my setup (@babel/preset-env takes 3.6 seconds)
• jsdom - 1.2 seconds in isolation
• sane - 0.5 seconds in isolation, most of which is caused by micromatch 3.

For JSDOM, there is already some work for cutting down dependencies and thus improving load times. They also have an active issue regarding request, which takes my machine .25 seconds to load.

An actionable item for the jest team might be replacing sane.

This right here is the issue ☝️

I really, really wish Jest would provide an option not to reload the entire module tree on every single test suite. We write our code in a mostly pure style and do not use mutable global state so it is a complete waste for us to be reloading modules every time. And it is a huge waste: a typical test suite in our code base takes 16 seconds to run, and < 1 second of that is running the actual test!

Thanks guys!

Sure: https://github.com/pelotom/storybook-bug-11571

Hi @shilman, I tried with the latest and it's still happening.

Ping? Just want to make sure this doesn't fall thru the cracks before the release!

@akessner something like this?

interface I<T> {
    P1: T;
}

interface C<T extends I<any>> {
    P1: T extends I<infer X> ? X : never;
    P2: T;
}

interface A {
    P1: string;
}

let v1: C<A>;
let v2: C<C<A>>;

For example,

export const someStringState = atom({
  key: 'someString',
  default: '',
});

const elem = <RecoilRoot initializeState={({ set }) => set(someStringState, 42)}>...</RecoilRoot>

This should be a type error because 42 is not a string, but it isn't. The setter's type is given by

type SetRecoilState = <T>(
    recoilVal: RecoilState<T>,
    newVal: T | DefaultValue | ((prevValue: T) => T | DefaultValue),
) => void;

where DefaultValue is defined as {}, which means that any values except null or undefined are allowed. I'm not sure what the purpose of DefaultValue is here, but it's causing type safety to be lost.

I think the issue here is that many of us don't care about persisting our recoil state. For that use case there's really no need for us as users to think about these unique ID's, they're just a footgun.

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

No worries, thanks for the quick fix.

This is my fault, since the lib built and tested fine I thought maybe it was okay to leave out the exports. This change just restores the things that were formerly exported.

When you install 5.0, you will get compile errors like

Exported variable 'Foo' has or is using name 'InternalRecord' from external module ".../node_modules/runtypes/lib/types/record" but cannot be named.

if you use Record.

I get the following warning when running storyshots with the v6 beta:

(node:77094) DeprecationWarning: `configure()` is deprecated and will be removed in Storybook 7.0.
Please use the `stories` field of `main.js` to load stories.

even though I've already refactored to use main.js. It seems that initStoryshots may still be using configure under the hood?

It seems fine to me. Documentation would be good though!

I don't really have the spare cycles to work on this personally but you're welcome to open a PR 🙂 This blog post might be a good starting point: https://2ality.com/2019/10/hybrid-npm-packages.html

Bumps acorn from 5.7.3 to 5.7.4. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/acornjs/acorn/commit/6370e90067552022710190319cbbbd8c43001957"><code>6370e90</code></a> Mark version 5.7.4</li> <li><a href="https://github.com/acornjs/acorn/commit/fbc15b1344f6dfb992f67b4bbf1357436247c8a0"><code>fbc15b1</code></a> More rigorously check surrogate pairs in regexp validator</li> <li>See full diff in <a href="https://github.com/acornjs/acorn/compare/5.7.3...5.7.4">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

The fix uses execSync to get the path output from npm bin rather than embedding the Bash-specific $(npm bin) in the command. I tested it successfully on Windows 10 and Ubuntu.

This seems to work, but I have some questions/concerns:

• The test stuff is completely arbitrary and I don't know if what I've done really follows the intent
• Not sure I named things the way you like - I decided to just be symmetric with Record
• Now partial.ts is basically a carbon copy of record.ts...it's just begging to be refactored

Thoughts?

Fixes #152

asReadonly() only seems to exist on Array and Record types. Would it be easy to extend this to support Partial as well? e.g. I'd like to be able to do:

Record({
  required: Number
}).asReadonly().And(Partial({
  optional: Number
}).asReadonly());

// -> {readonly required: number;} & {readonly optional?: number | undefined;}

I'd be open to generating an ES target as well, how would you propose doing it? Publishing a separate runtypes-es package to NPM a la lodash-es?

Hi NMarrero, thanks for the bug report. Would you be interested in making a PR to fix it?

The partial reflect variant should be removed since it's been subsumed by record now, right?

This appears to have been introduced in 6.0.0-beta.33.

Using these stories:

import { storiesOf } from '@storybook/react';
import React from 'react';

storiesOf('test', module)
  .add('x y', () => {
    console.log('render x y'); 
    return <div>x y</div>
  })
  .add('x', () => {
    console.log('render x');
    return <div>x</div>
  });

if you start on the "x" story and then reload the page, it will switch to the "x y" story, and the console prints

render x y
render x
render x y
``

(In my real project using typescript it actually switches between the 2 stories many more times, sometimes endlessly.)

This seems somehow related to the fact that the second story's name is a prefix of the first. If you change the second story name to "x z" the bug doesn't occur. It also doesn't occur if you change the order of the stories or change which one is selected at the beginning.

This seems to happen in cases where a static property is assigned to a component which is exported at its declaration site, e.g.

export default function Foo() {
  return null;
}
Foo.x = 42;

A workaround seems to be separating the export from the declaration:

export default Foo;
function Foo() {
  return null;
}
Foo.x = 42;

Class components with static properties suffer from the same problem:

export default class Foo() {
  static x = 42;
  render() { return null; }
}

and the workaround is the same:

export default Foo;
class Foo() {
  static x = 42;
  render() { return null; }
}

Ah, I am using Chromatic, thanks for the tip!

@pelotom I'm not sure about your use case, but the use case I see about using exclude would be maybe if I'm developing CheckoutFeature and I only want Storybook to bring those stories because maybe the project has like 500 stories. But in this scenario, rather than excluding, I would make my glob more specific and I would achieve that with the existing implementation of Storybook. Does that help somehow?

My use case is that I have one particular directory of stories nested deep within my repo which I want to exclude during visual regression testing in CI. It's not practical to positively specify all the things I do want to include while omitting this one particular deeply-nested directory, if that makes sense. My short term workaround is just to delete the directory in the CI script before building the storybook, but it'd be nice to have an exclude option.

@pelotom the downside as I see it is using PropsWithChildren for a situation where.... well where there are no props. See the impedance mismatch there? It really looks like what you want is ReactNode, no? While I'm not deeply opposed to the default argument... it seems kinda backwards to default to not having props for a type that intends to type props, know what I mean?

{} is a set of props (the empty set), so PropsWithChildren is still an accurate name. In any case, I don't really care about the name, I care that the type is useful, and it would be more useful if it had a defaulted parameter. Re. using ReactNode, as I said above, writing { children: ReactNode } is more cumbersome than writing PropsWithChildren.

• The test stuff is completely arbitrary and I don't know if what I've done really follows the intent

What do you mean by arbitrary?

• Now partial.ts is basically a carbon copy of record.ts...it's just begging to be refactored

I agree, what do you think about making Record take an optional argument which marks it as partial, and then Partial just being an alias to Record with that flag set?

This is our team's number 1 pain point with GH actions, would love to see something like this implemented, or alternatively support for YAML anchors (how we used to accomplish DRY with Travis).

Is there any way around this issue in checkout@v2? With checkout@v1 we were able to make use of the origin/master ref, but mysteriously it is no longer available in v2. I need v2 due to this, but also need access origin/master for use with Jest's --changedSince. Has anyone found a workaround?

Presumably this is why the latter exists in the first place.

Sure but the name makes it clear that it is about "props and children". If you're not passing "props" then the type looses its meaning and it should make it obvious when you forgot the props. In the end you can always do PropsWithChildren<{}> if you are sure you don't have any props, no?

It's a minor convenience. What's the downside?

function MyComponent({ children }: PropsWithChildren) {

I think we have it pretty well established that React.ReactNode is the dedicated type for children. Do we need this specific pattern you suggested for anything else?

Not sure if this is what you’re suggesting, but writing { children: ReactNode } is more cumbersome than PropsWithChildren. Presumably this is why the latter exists in the first place.

Please fill in this template.

• [x] Use a meaningful title for the pull request. Include the name of the package modified.
• [x] Test the change in your own code. (Compile and run.)
• [x] Add or edit tests to reflect the change. (Run with npm test.)
• [x] Follow the advice from the readme.
• [x] Avoid common mistakes.
• [x] Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If changing an existing definition:

• [ ] Provide a URL to documentation or source code which provides context for the suggested changes: <<url here>>
• [ ] If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• [ ] Include tests for your changes
• [ ] If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

Any chance this could get released soon? This is a major blocker for us since we can't practically run all of our tests in CI on every PR.

<!-- Love Jest? Please consider supporting our collective: 👉 https://opencollective.com/jest/donate -->

🐛 Bug Report

I am using moduleNameMapper to match my TypeScript paths settings. The tests run fine, but if I use --onlyChanged, --changedSince or --findRelatedTests it doesn't pick up tests which depend on changed files via mapped paths. <!-- A clear and concise description of what the bug is. -->

To Reproduce

Steps to reproduce the behavior:

1. Clone this repo: https://github.com/pelotom/module-name-mapper-bug
2. Make a change to packages/foo/src/index.ts
3. Run yarn test

Expected behavior

The tests in both packages/foo and packages/bar should be run, since the test in bar depends on packages/foo/index.ts indirectly via the remapped name '@nighttrax/foo'.

<!-- A clear and concise description of what you expected to happen. -->

Actual behavior

Only the test in packages/foo runs.

Link to repl or repo (highly encouraged)

https://github.com/pelotom/module-name-mapper-bug

Never mind, I figured out that this was due to not setting roots to include all my subpackages.

Yes, it works in 6.0.0-beta.23 and before. I don't have a minimal repro currently, but can work on putting one together.

It appears that a change introduced in 6.0.0-beta.24 is causing my storybook to fail to load:

I'm not sure exactly what is going on here because source maps don't seem to be working.

<!-- Love Jest? Please consider supporting our collective: 👉 https://opencollective.com/jest/donate -->

🐛 Bug Report

I am using moduleNameMapper to match my TypeScript paths settings. The tests run fine, but if I use --onlyChanged, --changedSince or --findRelatedTests it doesn't pick up tests which depend on changed files via mapped paths. <!-- A clear and concise description of what the bug is. -->

To Reproduce

Steps to reproduce the behavior:

1. Clone this repo: https://github.com/pelotom/module-name-mapper-bug
2. Make a change to packages/foo/src/index.ts
3. Run yarn test

Expected behavior

The tests in both packages/foo and packages/bar should be run, since the test in bar depends on packages/foo/index.ts indirectly via the remapped name '@nighttrax/foo'.

<!-- A clear and concise description of what you expected to happen. -->

Actual behavior

Only the test in packages/foo runs.

Link to repl or repo (highly encouraged)

https://github.com/pelotom/module-name-mapper-bug

Ping?

I don't know Deno, but if it doesn't allow for dependencies to be compiled under different configuration than your own project that seems like a pretty severe design flaw IMO (one which regular TypeScript does not suffer from). BTW, this project is using the stricter setting: by not using a default case and instead relying on exhaustiveness checking to prove that the function is still total, it protects from the situation where you add another case but fail to handle it in the switch statement. If you add another case to Reflect, you will suddenly have a type error in that function because it is not exhaustive.

It’s using the official tsc. Maybe the default tsconfig is different?

You would need to make it use the tsconfig in the root of this repo.

I’m not building it, I use it with Deno which supports TS natively.

Apparently not fully, if it's reporting errors when yarn build does not. Does Deno not support exhaustiveness checking?

error TS2349: This expression is not callable.
  Type 'never' has no call signatures.

► http://localhost:8000/raw.githubusercontent.com/pelotom/runtypes/master/src/show.ts:65:9

65   throw Error('impossible');
           ~~~~~

I'm not sure how you're trying to build the library but if you run yarn && yarn build it should work.

I would rather not add a dependency on a particular bundler to this library. Is there a way to re-do the imports so as not to confuse your bundler?

That's reasonable, would you like to make a PR?

First of all, AWESOME library! One thing has been bugging me about it though and its support for Discriminated Unions.

This is my attempt on addressing it, and I've seen similar issues being raised too.

So with this PR, when those conditions are met:

• all the alternatives of a union are records
• they have at least one field in common, that is a literal in each record with unique values

Then when checking the alternatives we can pick the correct one first, and then perform the validation, thus producing more specific error messages.

This is something already present in TypeScript itself https://www.typescriptlang.org/docs/handbook/advanced-types.html#discriminated-unions and seems to have been requested before https://github.com/pelotom/runtypes/issues/67 . Though this implementation would not work in all the cases covered by TS, but it's a start.

I'll be glad to add more tests or work on the implementation on your direction. Sorry for the long implementation, but the you seem to be supporting way older version of JS than I'm used to so had to implement the logic in for loops and such.

Fixes #414

When using better-sqlite3 in Jest, if we have more than 1 test suite which imports sqlite3 and sets a pragma:

const sqlite3 = require('better-sqlite3');

test('set pragma', () => {
  sqlite3().pragma('foreign_keys = ON');
});

the second suite fails:

    TypeError: Expected first argument to be a string

      2 |
      3 | test('set pragma', () => {
    > 4 |   sqlite3().pragma('foreign_keys = ON');
        |             ^
      5 | });
      6 |

      at Database.pragma (node_modules/better-sqlite3/lib/pragma.js:7:41)
      at Object.<anonymous> (set-pragma-9.test.js:4:13)

There is also a memory leak. I think both of these are due to the monkey patching here: https://github.com/JoshuaWise/better-sqlite3/blob/6be0b0ec618864764a4b2b28ea83d2fe1126a2a3/lib/database.js#L38 When Jest resets its module cache, this code is re-run and the wrapper is applied to the previous wrapper. Repro repo: https://github.com/pelotom/better-sqlite3-jest-bug

I can't seem to make that work, it ends up excluding all files.

The new main.js format for specifying stories requires specifying an array of globs, e.g.

module.exports = {
  stories: ['../../src/**/*.@(story|stories).tsx'],
};

With this approach it's not clear how I can exclude certain things from being included. When the stories were configured within the browser environment I was able to use require.context with a regex, e.g.

configure(
  require.context('../../src', true, /(?<!\/some\/forbidden\/directory.*)\.(story|stories)\.tsx?$/),
  module,
);

I could walk the directory structure in node and just provide a large array of fully resolved file paths, but it'd be nice to just be able to provide a regex instead of a glob. Or is there a way to do this with globs that I'm missing?

When I simply try to require sqlite3 from a Jest test with the --detectLeaks flag, it says there is a memory leak. Repro here: https://github.com/pelotom/sqlite3-jest-memory-leak.

As explained in this article this may just be due to the way that Jest unloads and reloads modules to ensure isolation between runs. It doesn't look like much memory is being leaked; my main issue is that it prevents me from using --detectLeaks to find other worse leaks.