-
Notifications
You must be signed in to change notification settings - Fork 36
Do not log a warning on null
subpath exports
#810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not log a warning on null
subpath exports
#810
Conversation
|
Was there stdout spam previously? Can we edit a package.json |
Yeah, here's what prompted this:
With a "exports": {
// ...
"./*": {
"types": "./dist/*.d.ts",
"default": "./dist/*.js"
},
"./internal/*": null
} I'm still trying to figure out how to repro this behavior in a test |
If you search for |
@@ -3,6 +3,7 @@ | |||
"private": true, | |||
"exports": { | |||
".": "./src/main.js", | |||
"./stars/*": "./other/*.js" | |||
"./stars/*": "./other/*.js", | |||
"./stars/internal/*": null |
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.
If I do this on main
and then change this from BazelLog.Warnf("unknown exports.%s type: %T", exportKey, export)
to BazelLog.Fatalf("unknown exports.%s type: %T", exportKey, export)
I can get bazel test --test_output=all //gazelle/js:npm_package_deps_test
to fail.
But I think this is interfering with expectedStdout.txt
/ expectedStderr.txt
🤔
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.
Oh, was it only logging and not spamming stdout? Then with tests the logging wasn't even visible...?
If so then just adding this line to this test is enough 👍
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.
What I'm seeing in our codebase is that bazel configure
logs a message like this for each null
in "exports"
:
2025/02/06 07:51:30 unknown exports../internal/* type: <nil>
I'm not sure where the line is between logging and spamming -- I was mostly just trying to pre-empt questions from devs in our repo since having a null
in "exports"
in this case is intentional.
I didn't dig in to how the epectedStdout.txt
/expectedStderr.txt
is implemented, but I confirmed that on main
adding "./stars/internal/*": null
here causes us to hit the BazelLog.Warnf("unknown exports.%s type: %T", exportKey, export)
statement. During tests it looks like the logger writes to a file so it never makes it to stdout
/stderr
. If I comment out this I can get a failing test:
Synced from #810 by walkerburgin: --- Small quality of life improvement to stop logging a warning on `null` subpath exports in `package.json`: ```json { "exports": { "./features/*.js": "./src/features/*.js", "./features/private-internal/*": null } } ``` --- ### Changes are visible to end-users: yes - Searched for relevant documentation and updated as needed: yes - Breaking change (forces users to change their own code or config): no - Suggested release notes appear below: yes Do not output `aspect configure` warning for package.json 'null exports' ### Test plan - Covered by existing test cases - Manual testing; please provide instructions so we can reproduce: Closes #810 Co-authored-by: Walker Burgin <wburgin@anduril.com> GitOrigin-RevId: e4d41609ed4bf14f13d6b975a9df023558a0d9be
Synced from #810 by walkerburgin: --- Small quality of life improvement to stop logging a warning on `null` subpath exports in `package.json`: ```json { "exports": { "./features/*.js": "./src/features/*.js", "./features/private-internal/*": null } } ``` --- ### Changes are visible to end-users: yes - Searched for relevant documentation and updated as needed: yes - Breaking change (forces users to change their own code or config): no - Suggested release notes appear below: yes Do not output `aspect configure` warning for package.json 'null exports' ### Test plan - Covered by existing test cases - Manual testing; please provide instructions so we can reproduce: Closes #810 Co-authored-by: Walker Burgin <wburgin@anduril.com> GitOrigin-RevId: e4d41609ed4bf14f13d6b975a9df023558a0d9be
Synced from #810 by walkerburgin: --- Small quality of life improvement to stop logging a warning on `null` subpath exports in `package.json`: ```json { "exports": { "./features/*.js": "./src/features/*.js", "./features/private-internal/*": null } } ``` --- ### Changes are visible to end-users: yes - Searched for relevant documentation and updated as needed: yes - Breaking change (forces users to change their own code or config): no - Suggested release notes appear below: yes Do not output `aspect configure` warning for package.json 'null exports' ### Test plan - Covered by existing test cases - Manual testing; please provide instructions so we can reproduce: Closes #810 Co-authored-by: Walker Burgin <wburgin@anduril.com> GitOrigin-RevId: e4d41609ed4bf14f13d6b975a9df023558a0d9be
Synced from #810 by walkerburgin: --- Small quality of life improvement to stop logging a warning on `null` subpath exports in `package.json`: ```json { "exports": { "./features/*.js": "./src/features/*.js", "./features/private-internal/*": null } } ``` --- ### Changes are visible to end-users: yes - Searched for relevant documentation and updated as needed: yes - Breaking change (forces users to change their own code or config): no - Suggested release notes appear below: yes Do not output `aspect configure` warning for package.json 'null exports' ### Test plan - Covered by existing test cases - Manual testing; please provide instructions so we can reproduce: Closes #810 Co-authored-by: Walker Burgin <wburgin@anduril.com> GitOrigin-RevId: e4d41609ed4bf14f13d6b975a9df023558a0d9be
Small quality of life improvement to stop logging a warning on
null
subpath exports inpackage.json
:Changes are visible to end-users: yes
Test plan