[Bug]: Missing type definition for pretty-format/ConvertAnsi plugin

[sounisi5011]

Version

pretty-format 28.0.0+

Steps to reproduce

1. Install [email protected]

2. Setup TypeScript 4.7+ by setting the moduleResolution flag to "Node16" or "NodeNext" in tsconfig.json.

   {
     "compilerOptions": {
       "module": "Node16", // or "NodeNext"
       "noImplicitAny": true // This flag is required to disallow "any" type.
     }
   }

3. Write the following code:

   import ConvertAnsiPlugin from 'pretty-format/ConvertAnsi';
   
   // ...

4. Run tsc

Expected behavior

Import will succeed. No TypeScript error is generated due to module import.

Actual behavior

TypeScript reports the following error:

error TS7016: Could not find a declaration file for module 'pretty-format/ConvertAnsi'. '<your-project-directory-path>/node_modules/pretty-format/build/plugins/ConvertAnsi.js' implicitly has an 'any' type.
  If the 'pretty-format' package actually exposes this module, try adding a new declaration (.d.ts) file containing `declare module 'pretty-format/ConvertAnsi';`

Additional context

The reason is missing build/plugins/ConvertAnsi.d.ts file in published npm package.

With #12308, it is now possible to import ConvertAnsi plugins directly. In addition, TypeScript 4.7 now supports the exports field.

Until pretty-format 27.5.1, the type definition file build/plugins/ConvertAnsi.d.ts corresponding to the build/plugins/ConvertAnsi.js file was included in the package and could be imported successfully. However, since pretty-format 28.0.0, all type definition files in the subdirectories have been removed and only the build/index.d.ts file exists.

Difference between published pretty-format 27.5.1 and pretty-format 28.0.0 by Renovate

Environment

System:
    OS: macOS Mojave 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz
  Binaries:
    Node: 14.19.3 - ~/.anyenv/envs/nodenv/versions/14.19.3/bin/node
    Yarn: 1.22.18 - /usr/local/bin/yarn
    npm: 6.14.17 - ~/.anyenv/envs/nodenv/versions/14.19.3/bin/npm

[mrazauskas]

Have you tried this:

import { plugins } from 'pretty-format';

plugins.ConvertAnsi;

[sounisi5011]

Yes, plugins.ConvertAnsi is available. It is equal in feature and value.

However, import ... from 'pretty-format/ConvertAnsi' is not available.

A workaround exists, but I think it is a bug that this feature, which is also described in CHANGELOG, is not available only in TypeScript.

[mrazauskas]

Hm.. Not sure if the only documented way of importing plugins can be called a workaround. See readme section Usage with plugins.

[mrazauskas]

@SimenB It would be easy to get back the missing .d.ts by not bundling types of pretty-format. Not sure if I like this, sounds like a workaround.

Also it does not look like the 'pretty-format/ConvertAnsi' export was meant to be imported into TS. The use case was this:

https://github.com/facebook/jest/blob/4da4a42d7bc7456d1139769b4df0c0a361e68e83/jest.config.mjs#L38

Perhaps it makes sense to look for alternatives instead of the 'pretty-format/ConvertAnsi' export? For example:

• a magic-string snapshotSerializers: 'pretty-format/ConvertAnsi']
• the plugin published as separate pretty-format-ansi library under Jest Community

I like the latter the best. The plugin would have own .d.ts, it would work with the use case above and would clean up "exports" of pretty-format.

What do you think?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[mrazauskas]

@sounisi5011 Just to draw your attention. Recently I published jest-serializer-ansi-escapes. It is inspired by ConvertAnsi plugin, but does much more:

• serializes cursor control as well as color and style escapes
• uses descriptive strings for reset escapes, e.g. </intensity>, </underline>
• supports vanilla sequences with more than one argument (\u001b[1;31m becomes <bold, red>)

I wrote it for one of my projects. Perhaps it might help to solve your issue too?

[sounisi5011]

@mrazauskas Thank you very much. I appreciate it.

But what I am wanting is consistent behavior of multiple import ways. In other words, the goal is to have both import { plugins } from 'pretty-format'; const ConvertAnsiPlugin = plugins.ConvertAnsi and import ConvertAnsiPlugin from 'pretty-format/ConvertAnsi' available in the TypeScript import statement.

I thought #12308 would also solve the traditional redundant import method of "import plugins objects and then use the ConvertAnsi property in plugins object". So I considered this current situation to be a bug. I thought the reduction of the type definition file was what caused this unintended problem. Therefore, I opened this issue.

However, if #12308 did not consider such a use case at all, it is my mistake. I leave it to the maintainers to decide if this issue should be resolved.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.