-
Notifications
You must be signed in to change notification settings - Fork 803
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
refactor: remove "export *" in favor of explicit named exports #4880
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4880 +/- ##
==========================================
+ Coverage 91.04% 93.64% +2.60%
==========================================
Files 89 269 +180
Lines 1954 6688 +4734
Branches 416 1325 +909
==========================================
+ Hits 1779 6263 +4484
- Misses 175 425 +250 |
Remove special case eslint rule from API.
Sanity check before the rewrite of export * as nameSpace to explicit exports under a nameSpace. Co-authored-by: Jamie Danielson <[email protected]>
I've gotta catch this branch up to |
@robbkidd thanks for working on this. I'm currently working on another large change for the OTLP exporters, so you can omit them in this PR for now. The exporters currently have differently named exports for web and node. This causes trouble when we're trying to convert them to explicitly named exports and also introduces some bugs along the way. The fix I'm working on will ensure that the exports for web and node are the same so that we don't run into that issue anymore. |
@@ -13,4 +13,144 @@ | |||
* See the License for the specific language governing permissions and | |||
* limitations under the License. | |||
*/ | |||
export * from './SemanticResourceAttributes'; | |||
export { |
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.
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.
I updated this branch to not change the semantic conventions export-all yet. Maybe that can happen as a part of #4690 and the code-generation?
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.
@robbkidd yes ignore semconv. The semconv package might end up keeping the export * for a couple reasons:
- it simplifies code generation
- it is only a "single level" of export, and most tree shakers can actually handle that.
To expand on (2), the issue with import *
is not that it is always bad, but that if you have some file that exports *, then another file re-exports that file, then maybe that happens with another file, tree shakers have a very hard time. Every tree shaker has a maximum number of levels that it tracks (many, such as eslint, are just 1 level). Additionally, because the semconv package only exports constants, there is no fear of reaching depth limits of tree shakers in other ways (circular references, deep objects, etc).
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.
There are two levels of re-export, at least in the current semconv package:
- ♻️ src/index.ts
- ♻️ src/resource/index.ts
- ⬆️ src/resource/SemanticResourceAttributes.ts (the real consts)
- ♻️ src/trace/index.ts
- ⬆️ src/resource/SemanticAttributes.ts (the real consts)
- ♻️ src/resource/index.ts
I see that the proposed new structure for semconv will have only one-level, so maybe it's fine to keep the two levels here in the deprecated paths?
7c927b0
to
040dd47
Compare
Mostly scripted. Thanks, Trent! Re-exports under namespaces and re-exports from another package were done by hand. We have intentionally not tackled NodeSDK yet. Awaiting feedback on this approach so far before updating that package. OTLP exporters omitted from this pass because work is in progress on them in other branches. Co-authored-by: Trent Mick <[email protected]> Co-authored-by: Jamie Danielson <[email protected]>
Co-authored-by: Jamie Danielson <[email protected]>
040dd47
to
6b46bd8
Compare
Updated the comment to remove the TODO because there is no expected followup. SemConv will use `export *` of the generated constants.
I think we can mark this TODO as complete, I've added as a comment to the issue. |
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.
Thanks for doing this.
This change was pleasantly fewer lines of change than I expected this.
- I have one Q below about an added devDep.
- This needs a changelog entry.
To somewhat test this I wrote a script to check that the CommonJS exported names from every built .js file is the same before and after:
https://gist.github.com/trentm/e93843753d7bb2b049566fbddb4c1fc4
And they are the same.
integration-tests/api/package.json
Outdated
"@types/mocha": "10.0.7", | ||
"@types/node": "18.6.5", | ||
"codecov": "3.8.3", | ||
"cross-var": "1.1.0", | ||
"lerna": "6.6.2", | ||
"mocha": "10.0.0", | ||
"nyc": "15.1.0" | ||
"nyc": "15.1.0", | ||
"ts-node": "^10.9.2" |
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.
Do you know why this ts-node
devDep was added?
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.
🤔 I wonder if we left that in when trying out some other integration tests. Doesn't look like we ended up using it for anything, should be okay to drop.
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.
I think the way we've set it up now will always require ts-node
when we're using mocha
, even if we're just feeding it JavaScript code (see ./.mocharc.yml
, which is the closes mocha config file).
So I think we'd actually need to add this ts-node
dependency here.
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.
Do you know why this
ts-node
devDep was added?
… I did last week.
I removed ts-node
from package.json
and the root package-lock.json
, rm'd root ./node_modules
, ran npm run reset
, then this integration test cd integration-tests/api && npm run test
, and the tests ran and passed. So … I can't explain the dev need for ts-node any more.
Update: I removed ts-node from the devDeps and the test suite seems fine.
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.
Regarding changelog entries: should supply multiple entries to a CHANGELOG (one entry for every package touched in the closest parent CHANGELOG)? I would model each entry's content on this past exports refactoring.
Changelogs!
❯ find ./ -type d -name node_modules -prune -o -name CHANGELOG.md -print | sort
.//CHANGELOG.md
.//api/CHANGELOG.md
.//experimental/CHANGELOG.md
.//experimental/packages/otlp-transformer/protos/CHANGELOG.md
.//scripts/semconv/opentelemetry-specification/CHANGELOG.md
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.
I think we should skip the changelog in the otlp-transformer package and the scripts directory, so we'd maybe want only in these:
.//CHANGELOG.md
.//api/CHANGELOG.md
.//experimental/CHANGELOG.md
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.
Changelog entries added in fbe156f. I opted to list each package individually in sub-bullets because I didn't see prior art for very long lists of updated packages. I'm happy to adjust that content—flatten to a single bullet with a comma-separated list, put the long list in refactor(...):
, remove the list—however y'all see fit.
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.
Update: I removed ts-node from the devDeps and the test suite seems fine.
I understand the ts-node dep now. Marc's comment is correct. In #4840 we switched from using ts-mocha
to just using mocha
directly with a config file (https://github.com/open-telemetry/opentelemetry-js/blob/main/.mocharc.yml) that uses ts-node
(to handle the compilation of TS to JS). That means that technically any package.json file with a "mocha" devDep should also have a "ts-node" devDep. Because we are using npm workspaces with a shared top-level node_modules/...
folder, any single package.json have a ts-node devDep that gets installed at the top-level saves us. And there are three:
% rg ts-node -g package.json
packages/opentelemetry-semantic-conventions/package.json
90: "ts-node": "10.9.2",
experimental/examples/events/package.json
6: "start": "ts-node index.ts"
18: "ts-node": "^10.9.1"
experimental/examples/logs/package.json
6: "start": "ts-node index.ts",
16: "ts-node": "^10.9.1"
So, technically adding that devDep here was a good thing, but this is hardly the only transgressor. There are 3 package.json's with the "ts-node" dep and 44 with the "mocha" dep:
% rg '"mocha":' -g package.json | wc -l
44
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.
Just one nit about the location of the @opentelemetry/core
integration test.
Thank you for working on this, looks great 🙂
api-entries is about api; core-entries is about core. Both are still under ./integration-tests/api, but maybe that's OK?
Maybe we don't need ts-node here after all?
I think everything has been updated to match feedback, with the last missing piece being the changelog(s) entry. I mention in this comment that we should probably have a changelog in root, api, and experimental. This seems to match the note in root changelog as well, which makes me wonder whether those other changelogs should still exist or be removed. That is not something to address here though. # CHANGELOG
All notable changes to this project will be documented in this file.
For API changes, see the [API CHANGELOG](api/CHANGELOG.md).
For experimental package changes, see the [experimental CHANGELOG](experimental/CHANGELOG.md). |
…telemetry#4880) Co-authored-by: Jamie Danielson <[email protected]> Co-authored-by: Trent Mick <[email protected]> Co-authored-by: Marc Pichler <[email protected]>
Which problem is this PR solving?
export * from ...
so that all exports (and imports) are explicit #4186Short description of the changes
_globalThis
explicitly."no-restricted-syntax": ["warn", "ExportAllDeclaration"]
for themexport *
'ing untouched by this PR to Change / Ban all usages ofexport * from ...
so that all exports (and imports) are explicit #4186 for trackingexport * untouched by this PR
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: