Dom-testing-library: Reduce dependency count

[Raynos]

Describe the feature you'd like:

Reduce the number of dependencies installed when installing dom-testing-library. The feature set of this package is fantastic for anyone writing tests against the DOM.

Being able to query against the DOM in the language of your users and using waitFor & other techniques to deal with asynchronous frameworks is really really nice.

Currently when I install this library I get

├─┬ @testing-library/[email protected]
│ ├─┬ @babel/[email protected]
│ │ └── [email protected]
│ ├─┬ [email protected]
│ │ ├── @babel/[email protected] deduped
│ │ └─┬ @babel/[email protected]
│ │   ├── [email protected]
│ │   └── [email protected] deduped
│ ├── [email protected]
│ └─┬ [email protected]
│   ├─┬ @jest/[email protected]
│   │ ├── @types/[email protected]
│   │ ├─┬ @types/[email protected]
│   │ │ ├── @types/[email protected] deduped
│   │ │ └─┬ @types/[email protected]
│   │ │   └── @types/[email protected] deduped
│   │ ├─┬ @types/[email protected]
│   │ │ └── @types/[email protected]
│   │ └─┬ [email protected]
│   │   ├── [email protected] deduped
│   │   └─┬ [email protected]
│   │     └── [email protected]
│   ├── [email protected]
│   ├─┬ [email protected]
│   │ ├── @types/[email protected]
│   │ └─┬ [email protected]
│   │   └── [email protected] deduped
│   └── [email protected]

29 dependencies, from these it looks like only ( @testing-library/dom ; dom-accessibility-api ; aria-query ; pretty-format ; ansi-styles ; color-convert ; color-name ) are useful dependencies.

It would be great if installing this library only installed 3 dependencies and if it had 4 optional dependencies ( pretty-format & ansi-* make great optional dependencies )

Suggested implementation:

To reduce dependency count the following could be implemented

• Removing babel dependency
• Remove nested babel dependency from aria-query
• Make pretty-format an optional dependencies
• Remove @jest/types from pretty-format or replace pretty-format with a smaller library.

Describe alternatives you've considered:

:shrug:

Teachability, Documentation, Adoption, Migration Strategy:

Having an optional dependency does require teaching users that pretty-format can be installed to pretty print the errors and warnings generated by dom-testing-library.

Your tests will work fine as is but might not be as pretty when looking at the output of a test failure without having installed pretty-format

An optional dependency looks like

let prettyFormat
try {
  prettyFormat = require('pretty-format')
} catch (err) {
  console.warn('If you would like a pretty error; please npm install pretty-format')
}

/* ... */

// In the library itself; wrap every usage of `prettyFormat` in a ternary or if statement
console.log(prettyFormat ? prettyFormat(x) : x)

[eps1lon]

Having readable error messages is an essential part of a good testing setup in my opinion. Your dependency tree is 50% made up of types. What would you gain by having a smaller tree?

[Raynos]

What would you gain by having a smaller tree?

I am whitelisting and auditing all the code I install for security. Every dependency is something I have to read, I have to whitelist that module name, I have to audit the authors that publish it to npm.

Also, every dependency I install is something I might have to fork, maintain and fix if my app is being used on a longer term then the author of the package maintains his package.

Less dependencies, less problems.

Currently my application looks like this

$ npm ls --dev
my-app @ 1.0.4
├── @pre-bundled/[email protected]
├── @pre-bundled/[email protected]
├── @types/[email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected] ({private})
└── [email protected]
$ npm ls --prod
my-app @ 1.0.4
├── @optoolco/[email protected]
├── @optoolco/[email protected]
├── @raynos/[email protected] ({internal})
├── @raynos/[email protected] ({internal})
├── @raynos/async-level {internal}
├── @raynos/[email protected] ({internal})
├── @raynos/[email protected] ({internal})
├─┬ @raynos/[email protected] ({internal})
│ ├── @raynos/[email protected] ({internal})
│ ├── @raynos/[email protected] deduped ({internal})
│ └── [email protected] deduped
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
└── [email protected]
├─┬ [email protected]
│ ├─┬ {16 nested deps ... aws-sdk is whitelisted and critical}
├─┬ [email protected]
│ ├─┬ {7 nested deps ... leveldb database driver is whitelisted and critical}

I've audited all my dependencies and chosen two whitelist two critical third party libraries ( aws-sdk & leveldown )

[Raynos]

Having readable error messages is an essential part of a good testing setup in my opinion.

I'm fine with installing pretty-format by default. As an alternative to an optional dependency we could vendor it. ( https://github.com/Raynos/npm-bin-deps/blob/master/package.json#L8-L10 )

For example

cp -r node_modules/pretty-format/build ./vendor/pretty-format
sed -i /require('pretty-format')/require('./vendor/pretty-format')/
npm i ansi-regex ansi-styles react-is --save

[eps1lon]

As an alternative to an optional dependency we could vendor it.

So we would need to maintain it rather than the folks over at jest? That doesn't sound like a solution to me.

I understand the general concern but I don't agree with the extreme step to simply cut it. All of the listed dependencies (with the exception of dom-accessibility-api maybe) are maintained either by large orgs or long term OSS maintainers.

The security risk they pose seems to be on the same level as using testing-library itself. It sounds like there is some subtext here I'm not getting. Could you explain why pretty-format is such an issue for you?

[Raynos]

So we would need to maintain it rather than the folks over at jest? That doesn't sound like a solution to me.

You can have the folks at jest maintain it.

npm install pretty-format --save-dev

Then if you want to get a newer version of pretty-format

npm install pretty-format@latest --save-dev
cp -r node_modules/pretty-format/build ./vendor/pretty-format

You are correct that if a security hotfix of pretty-format is released you will have to manually release a new security hotfix of dom-testing-library .

This would be the same maintenance burden if you set the version of pretty-format in package.json to "pretty-format": "26.0.1" or "pretty-format": "~26.0.1" . There are people with different opinions on whether ^ ; ~ or exact versions are the best practice to follow.

[Raynos]

The security risk they pose seems to be on the same level as using testing-library itself. It sounds like there is some subtext here I'm not getting. Could you explain why pretty-format is such an issue for you?

There is no subtext; the particular modules being used are a not an issue. I mentioned pretty-format as proposing a solution for reducing dependency count; any solution to reducing dependency count is fine for me.

When I install a library I would prefer to install a library with zero dependencies.

As an example, the user experience of installing typescript or rollup ( both zero deps ) is great; the user experience of installing eslint or babel is frustrating.

I am also the author of https://github.com/Raynos/tapzero#tapzero and believe that installing 33MB of code to use a testing library like jest is insanity.

[kentcdodds]

Thanks for sharing your opinions @Raynos, but I think there's a values misalignment here so I don't expect this to go anywhere. Sorry.

[Raynos]

No worries; thanks for listening.