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

consolidate packages #306

Open
1 task done
tomwayson opened this issue Aug 3, 2020 · 9 comments
Open
1 task done

consolidate packages #306

tomwayson opened this issue Aug 3, 2020 · 9 comments

Comments

@tomwayson
Copy link
Member

tomwayson commented Aug 3, 2020

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
Copy link
Member Author

@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
Copy link
Contributor

@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
Copy link

@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
Copy link
Contributor

@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
Copy link
Member Author

tomwayson commented Sep 22, 2020

@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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

tomwayson commented Oct 19, 2020

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

image

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

@tomwayson
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants