package name discrepancies in suffixes: /core for stats vs /nodejs for tracing

[odeke-em]

Thank you for the work on the Node.js implementation!

I just noticed a weird discrepancy in the NPM package names.

For tracing, we need:

var tracing = require('@opencensus/nodejs');

For stats, we need:

var opencensus = require('@opencensus/core');
var stats = new opencensus.Stats();

What's the rhyme and reason behind the Node.js package names? nodejs as a suffix doesn't strike me as related to tracing, neither does core relate to stats. I ask because currently on the website we've got https://opencensus.io/guides/exporters/supported-exporters/node.js/ and I plan on writing many guides as well as actual framework and package integrations but would just like to get some clarity before embarking on that quest.

[mayurkale22]

I am not aware of the initial reasoning behind keeping tracing api in @opencensus/nodejs and stats in @opencensus/core. I think we should move everything from @opencensus/nodejs package to @opencensus/core package and deprecate @opencensus/nodejs. With this, it will be consistent with other language libraries and less confusion for users. This would be a breaking change, but worth to do it now.

@justindsmith @draffensperger @bogdandrutu @OsvaldoRosado WDYT?

[draffensperger]

I was wondering about that myself too. From a purely Node.js perspective, I think merging the two makes total sense. For the opencensus-web project though, what I'm hoping to do is import only interfaces and not the Node-specific implementations.

For that purpose, it might be nice to have some package like core-types that had only TypeScript interfaces with generic JS types (nothing Node-specific). That may have been part of the idea around the core package, but at this point core has a bunch of Node specific things, which I'm getting around in the opencensus-web project by using tree shaking with webpack. I can probably continue a similar workaround, but a separate interfaces only package would be nice.

[justindsmith]

Yes, the initial idea (from my understanding) was that core would hold non-environment-specific things and then nodejs would be the implementation for the nodejs environment, with the ultimate goal of being able to support a web environment as well. Apparently that's broken down, and was never really validated with any integration testing.

We could do a core-types package to separate interfaces and that should be pretty non-disruptive on the nodejs side other than work.

So I'm okay with removing nodejs, moving all node implementation into core, and moving types to a new core-types package.

[draffensperger]

Whether or not we end up doing the work to separate out a core-types package, I think at a minimum it would be useful to make sure that there are separate TypeScript interfaces for the core trace, stats and metrics API parts of the library (which I think there are now, just wanting that to continue as a best practice).