consolidate packages

[tomwayson]

Seems to me that there is unnecessary friction in the development and consumption of this library due the large number of packages.

The strategy of diving up the library into many micro-packages that are peer depenedencies came from rest-js. When we started work on that, tree shaking and code splitting were less reliable, and not available to the Ember apps that were going to use the packages. Neither of those are true any longer. We can now assume that most consumers of this library will use the ESM builds and be able to tree-shake out just the code that their apps need.

I think we could reduce the number of packages by about half if we:

• Consolidate auth and types into common
• Consolidate downloads and maybe search into content
• Consolidate teams into initiatives(?) or members(?)
• Consolidate sites into initiatives(?)

I think packages like events and surveys should independent for now at least.

[tomwayson]

@cpgruber what would you think about consolidating hub-surveys into hub-content?

@ajturner ultimately I could see a hub-feedback package that replaces hub-annotations and includes all that code and it would depend on the @hub-content package for survey related functions.

[cpgruber]

@cpgruber what would you think about consolidating hub-surveys into hub-content?

@ajturner ultimately I could see a hub-feedback package that replaces hub-annotations and includes all that code and it would depend on the @hub-content package for survey related functions.

I would defer to @rweber-esri and @brollison

[brollison]

@cpgruber I don't believe I have enough expertise here to comment in a helpful way; however, if a package called hub-feedback is meant to exist, then hub-surveys may be better suited there over hub-content. There is a lot we do or plan to do with surveys which treats them differently from most other content, but I'm not sure if that means they need to be separated from more generic content items.

// @rweber-esri please be more helpful / constructive than me ;-)

[rweber-esri]

@tomwayson

It may help to have a little more context into what the friction is specifically. Is the friction that people are having difficulty finding what they need or more along the lines of build/version bump pains (suspect the latter)? My main concern about consolidating the different type-specific packages into a more generic content package is centered around exporting & collisions. We do a lot of export * from "../wherever"; and could have some collisions that would force us to rename functions and/or add an abstraction layer like solutions-service in opendata-ui that delegates.

[tomwayson]

@rweber-esri

more along the lines of build/version bump pains (suspect the latter)

correct, though there's also pain in having to consume so many peer dependencies.

re: exporting and collisions, that's already an issue since our UMD builds put all the fns into a single namespace (arcgisHub).

[tomwayson]

My takeaway from this discussion is that we should essentially rename @esri/hub-annotatinos as @esri/hub-feedback and we can move the more specific code from @esri/hub-surveys into that new package and possibly the more generic code from @esri/hub-surveys (if any) into @esri/hub-content.

[tomwayson]

I've recently noticed that tree shaking of at least the @esri/hub-common package doesn't work in a new ember app.

I installed @esri/hub-common and it's peerDependencies and then added this line to the application controller: import { camelize } from '@esri/hub-common';. When I run ember s I see that there are hundreds of eval() statements, one for each ESM module in @esri/hub-common, and for the modules it depends on from arcgis-rest-js.

I think we ought to verify that tree shaking of these libraries works outside of ember-auto-import before too much further consolidation of pacakges.

[tomwayson]

Well the members package currently only exposes comingSoon() so it's not even doc'd:

So it's just there to slow down build times.

[tomwayson]

Here's my revised proposal on how to keep this moving along.

Frist, we do the no brainers:

• remove unused members package
• deprecate and remove annotations in favor of discussions

Next, we address #655, which makes dependency management from solution.js and template-js easier.

Then, we address #656, which makes dependency management for hub-components easier.

That will leave us with the following medium to large packages, but we should wait until we have our lazy loading strategy (i.e. #517) in place before merging them into common:

• surveys - this is a medium size, but stable package, last updated about a year ago, maybe under src/feedback?
• content - very large b/c of xml parsing library that we need to lazy load
• initiatives
• sites