Testing a package's public API

[altano]

The default way of using Vitest is to just directly import the file you are testing with a relative path, which obviously works.

There are some people (e.g. https://fosstodon.org/@rauschma/112066537954393244, see comments) who would like to test the public API of their package. In Node.js this is possible by just importing whatever you want to test by referencing your package name and your package.json "exports". It would look like this:

{
  "name": "my-awesome-fn",
  "type": "module",
  "exports": "./dist/awesomeFn.js"
}

import awesomeFn from "my-awesome-fn";

@ifiokjr asked about this feature in #1394 but @antfu closed that as "possible with resolve.alias". The problem with using resolve.alias is that the main use case of self-referencing your package is to test the package through the public API, and if you're manually replicating the behavior of package.json's exports field in resolve.alias you're not really testing the public API anymore.

Please reconsider implementing the specced Node.js module resolution in Vitest that allows self-referencing the package via package.json exports.

Thank you!

[hi-ogawa]

the main use case of self-referencing your package is to test the package through the public API, and if you're manually replicating the behavior of package.json's exports field in resolve.alias you're not really testing the public API anymore.

I understand this perspective, but Vite and Vitest's import resolutions and transforms are too forgiving compared to actual NodeJS runtime in many aspects, so if you need to test pure NodeJS use case, then Vitest is not technically a good fit (unless Vitest provides such stricter mode #3849).

Also, maybe this self-reference issue is simply a Vite bug and it looks like this is going to be fixed soon:

• Packages using self-referencing imports will fail to resolve ("moduleResolution": "node16" and package.json "exports") vitejs/vite#9731

[altano]

Thank you for replying. Yes, I understand your perspective as well: it's probably folly to rely on Vitest perfectly replicating the Node.js module resolution algorithm. I just hope this is one hole that can get addressed, given the specific and useful use case presented.

And thanks for that link, I missed it! I'm curious why you say it looks like it is going to be fixed soon, because the discussion in vitejs/vite#9731 doesn't seem to mention any potential fixes being on the way.

[hi-ogawa]

The issue is very old one, but there's a PR coming vitejs/vite#16068 and it's already approved by the team.

[altano]

@hi-ogawa since this was fixed and released in vite 5.2.0 (https://github.com/vitejs/vite/blob/v5.2.0/packages/vite/CHANGELOG.md#520-beta0-2024-03-12) can I expect this to work in the next release of vitest, whenever that happens to be?

Or is there something on the Vitest side that needs doing as well?

Thanks again!

[hi-ogawa]

Vitest doesn't pin Vite's version, so if you explicitly install Vite 5.2 for your project, then Vitest will use that one. Or you may be able to just upgrade transitive dependencies, for example, by pnpm dedupe https://pnpm.io/cli/dedupe

vitest/packages/vitest/package.json

Line 163 in c62b3a2

"vite": "^5.0.0",

[altano]

This has shipped in Vite 5.2.0 and can be used in Vitest today, so I'm closing this discussion.

Thanks so much @hi-ogawa for all your help!