Skip to content
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

Rename to opentelemetry-js? #20

Closed
draffensperger opened this issue Jun 6, 2019 · 14 comments
Closed

Rename to opentelemetry-js? #20

draffensperger opened this issue Jun 6, 2019 · 14 comments
Labels
Discussion Issue or PR that needs/is extended discussion.

Comments

@draffensperger
Copy link
Contributor

@rochdev had this idea in #6 (comment)

I would like us to make sure the core packages are compatible with the browser, and I think it will be easier to have Node + browser instrumentation code all living in the same repo to make it easier to keep everything up to date when refactorings happen.

I think the rename would be good for that purpose and to make it clear we are shooting for the broader JS community and not just Node, though Node will be the primary initial implementation target.

@mayurkale22
Copy link
Member

@bogdandrutu and @SergeyKanzhelev any thoughts?

@mayurkale22 mayurkale22 added the Discussion Issue or PR that needs/is extended discussion. label Jun 6, 2019
@bogdandrutu
Copy link
Member

If the goal is aligned across the SIG members to develop this package node independent I am fine with the raname. @mayurkale22 is everyone on board with this? Do you need an escalation on this?

@SergeyKanzhelev
Copy link
Member

Should there be another repo like -js-api? node and web may keep corresponding repositories with extra packages. Some logic may be very much node or web specific

@draffensperger
Copy link
Contributor Author

The downside to separate repos is that then refactoring is kind of hard, because you can't have a single PR that changes the API and also all the users of the API, and it's harder to keep the API in sync in the dependent packages between versions. In contrast, if it's all in one repo, you can make sure that changes to the API package pass all the CI tests for both Node-specific and browser-specific packages.

@SergeyKanzhelev
Copy link
Member

than it's for @open-telemetry/node-maintainers to decide. If you up for the challenge - than go ahead. There is an inercection of people who knows both worlds. But sometimes people are only familiar with either of two and it may be harder for them to contribute

@draffensperger
Copy link
Contributor Author

@mayurkale22 could you bring this up in the next SIG and see what people think?

@mayurkale22
Copy link
Member

@mayurkale22 could you bring this up in the next SIG and see what people think?

Sure, will update the thread once we have some conclusion after the meeting.

I'd prefer to keep both in the same repo., because we can work on both the version (server and browser) simultaneously without forcing us to publish to npm or other registries to share the types and core packages. And wherever is applicable we can mention, this package is intended for use both on the Node and in the browser.

@rochdev
Copy link
Member

rochdev commented Jun 7, 2019

I prefer a single repo as well. I used to be against it because I believed it promotes coupling, but then I realized that it's very possible to couple many repos together anyway. It also gets really painful to keep multiple repos in sync. This is even more true as the number of repos increases. It's also a lot easier for users who simply want to mix and match different packages if they all use the same version numbers.

@justindsmith
Copy link

My initial reaction is (also) to support the single-repo, but we can discuss further in the SIG.

@draffensperger
Copy link
Contributor Author

draffensperger commented Jun 8, 2019

What I did to manage keeping the types in sync between opencensus-web and opencensus-node was to write a kind of hacky copy-types script that would extract out only the type files from @opencensus/core for a specific Git commit. This worked around the Node-specific dependencies in @opencensus/core and enabled updating the types incrementally commit-by-commit as they changed in opencensus-node. But keeping it all in one package would simplify this.

For OpenCensus, the web and Node packages only share TS enums/interfaces. But for OpenTelemetry, I think it would be interesting to share actual code in the form of a common platform-neutral API similar to OpenTracing. Then there could be platform specific packages of the API for Node/web.

@rochdev
Copy link
Member

rochdev commented Jun 14, 2019

I believe there was an agreement to rename the repository. We should probably do that sooner rather than later since the more we wait the more contributors will be impacted.

@SergeyKanzhelev
Copy link
Member

@open-telemetry/node-maintainers can you please confirm that you requesting this change. Happy to accommodate.

@mayurkale22
Copy link
Member

@open-telemetry/node-maintainers can you please confirm that you requesting this change. Happy to accommodate.

👍

@SergeyKanzhelev
Copy link
Member

Renamed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Issue or PR that needs/is extended discussion.
Projects
None yet
Development

No branches or pull requests

6 participants