Change / Ban all usages of export * from ... so that all exports (and imports) are explicit

[MSNev]

Make all imports and exports explicit so that internal classes / objects etc are not inadvertently made public and become part of the public API.

[jdbadilla]

Would also recommend doing this, we are facing several issues from these type of imports.

[trentm]

I'd had a start at scripting this conversion back at #3976 (comment)
I could revive that to possibly help with a PR for this.

[github-actions]

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

[github-actions]

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

[pichlermarc]

@dyladan I undid some of the notes you put into the issue title for contribfest.

I have been thinking about how to best go about this in SDK 2.0 from a practical standpoint and I think we should do this as much as we can on main first. I've noticed some caveats when merging main into next.

When a new export is added on main it will often be caught by the export * there. In next we then implicitly drop this new feature when updating as we do not get a merge-conflict when merging main into next.

My proposal: experienced contributors can do this wherever possible on main (one package at a time). That being said, we'll need to be very careful with reviewing.

[github-actions]

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

[JamieDanielson]

To add more clarity on the expectations of this issue, here is my understanding of what should be done:

1. Change all export * from 'foo'; to export { foo } from 'foo'; for parity
2. Add the ESLint rule "no-restricted-syntax": ["error", "ExportAllDeclaration"], to error on these types of exports
3. Review the public API surface area to determine what should not be exported, what should be private, etc. This step is part of another issue and is considered out of scope for this particular issue.

Step 1 may be a single PR for the repo, or several smaller ones, which we are working through.
Step 2 will be done as part of that single PR, or after the changes have been made.
Step 3 is tracked separately in #3598

[JamieDanielson]

Packages remaining to be updated in otel-js core repo after #4880 merges:

• experimental/packages/exporter-logs-otlp-grpc/src/index.ts
• experimental/packages/exporter-trace-otlp-grpc/src/index.ts
• experimental/packages/exporter-trace-otlp-http/src/index.ts
• experimental/packages/exporter-trace-otlp-http/src/platform/browser/index.ts
• experimental/packages/exporter-trace-otlp-http/src/platform/index.ts
• experimental/packages/exporter-trace-otlp-http/src/platform/node/index.ts
• experimental/packages/opentelemetry-exporter-metrics-otlp-grpc/src/index.ts
• experimental/packages/opentelemetry-exporter-metrics-otlp-http/src/index.ts
• experimental/packages/opentelemetry-exporter-metrics-otlp-http/src/platform/browser/index.ts
• experimental/packages/opentelemetry-exporter-metrics-otlp-http/src/platform/index.ts
• experimental/packages/opentelemetry-exporter-metrics-otlp-http/src/platform/node/index.ts
• experimental/packages/opentelemetry-exporter-metrics-otlp-proto/src/index.ts
• experimental/packages/opentelemetry-sdk-node/src/index.ts
• experimental/packages/otlp-exporter-base/src/index.ts

[legalimpurity]

@JamieDanielson @dyladan if required I can pick this up.

[JamieDanielson]

@JamieDanielson @dyladan if required I can pick this up.

Thanks! We have actually now made the majority of changes for this particular issue, and are intentionally holding off on otlp exporter changes for a bit because of other refactoring currently underway with this issue. I should have written that comment when I last updated this issue and forgot. That said, if you see another usage in this repo of export * from ... that were not handled or commented upon in #4880 please feel free to open a PR with that change!

[legalimpurity]

no problem. I thought @robbkidd might be busy with something else hence was unassigned. thanks.

[JamieDanielson]

Because of the eslint rule added for "no-restricted-syntax", every remaining instance of "export * from" was intentionally set disabled. Final step on this issue is to review those packages that contain eslint-disable no-restricted-syntax and determine if things need to change, and/or if a comment needs to be updated. For example:

• Semantic conventions will likely stay as-is
• OTLP exporters are under a major refactor, which will remove some of these already

[trentm]

Remaining work here, I think:

• chore: remove obsolete comment #5426 will remove the last no-restricted-syntax usage in the exporters.
• refactor(sdk-node): fix eslint warning #5400 is proposing allowing the re-export-stars in the sdk-node package. I brought up a discussion in slack about possibly dropping some of these re-exports. We could also turn those into explicit re-exports, so that sdk-node is clear about what it is exporting rather than deferring to whatever the other packages export. Not sure. I don't have a strong opinion.

If we do allow exceptions, does that cause the same tslib-related breakage we saw before?

[pichlermarc]

#5400 is proposing allowing the re-export-stars in the sdk-node package. I brought up a discussion in slack about possibly dropping some of these re-exports. We could also turn those into explicit re-exports, so that sdk-node is clear about what it is exporting rather than deferring to whatever the other packages export. Not sure. I don't have a strong opinion.

I think the the only reason why these exports needed are to have types that are guaranteed to be compatible with the version that's expected by NodeSDK's public interface, so one does not have to exactly match versions to compile (I'm speculating on the reason, though it may very well be that whoever added it just thought it may be a nice-to-have to import everything from one package). For stable packages, we have eliminated most of the problematic types (View, MetricReader, Span) - but for experimental ones we're still in the same boat as their interfaces can actually break, so we may want to keep re-exporting them (ref #5283).

Personally I am in favor of removing them, but I'm not sure how many end-users actually use in the way I mentioned above. If we remove the re-exports for experimental packages too then I think we don't have a have a good alternative for these users.

Regarding this issue, everything that's in scope for SDK 2.0 is done now, I think. Any remaining changes can be done after the release in minor releases of the experimental @opentelemetry/sdk-node package, which can be breaking according to semver

[trentm]

Thanks.

Other than the contextBase re-export (that I'm calling "weird", possibly the node reexport as well), I'm slightly inclined to keep the re-exports in sdk-node for now to minimize the impact of all the API changes we're introducing in "SDK 2.0". Then perhaps we can remove/replace these re-exports later when we attempt to a re-design of the Node SDK -- inspired by Marc's epic on sdk-node. ;)

[trentm]

Our understanding is that for SDK 2.0, the current state is sufficient.
The export * from re-exports in sdk-node remain for now.
Our intention is to open a separate issue for these.
(If someone feels strongly, we are probably amenable to trying to drop these.)

I've opened #5461 for following up for the sdk-node package.