Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be in the exports section no?
But anyway, I'm not sure that's really useful and that we want to do that:
package.json
is not part of the public API we want to expose.What are you trying to achieve with this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did I put it in the wrong place? This comment in the linked issues indicates that it should be a sibling of the
"."
entry.As for what I'm trying to achieve, like I said in the PR description - I have some tooling I'm working on which is designed to assist with an upgrade from VTU 1 to VTU 2 (and which I would like to soon publish as open-source) which wants reads the installed version of VTU in order to decide how it should act. Since VTU hasn't been explicitly exporting its version number as part of its public interface anywhere I'm aware of I was trying to get it from the
package.json
.This comment suggests that it's not that uncommon for tooling ecosystems to read
package.json
. Indeed, it's whateslint-plugin-jest
does in order to detect which deprecation warnings it should emit.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is this would also go in
exports
, Cypress does something similar:https://github.com/cypress-io/cypress/blob/develop/cli/package.json#L119-L134.
That said, I am not super clear on why we need to list it in
exports
- wouldn't you just doconst pkg = require('@vue/test-utils/package.json')
? That would work for both VTU v1 and v2.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed, that is exactly what I am trying to do, and cause of the exports that are now defined, I can't (hence the PR). try it yourself:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird! I swear this used to work... I didn't even know Node 14 supported
exports
.I just tested, I think it should be:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edit: that's exactly what you did, LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
man, I was gonna say... am I hallucinating? I did make this edit in github's UI but I triple checked it so many times 😆