A2W gained weight after using Groundwork

[adamscarberry]

The lighthouse performance score went from 76 to 56.

Trying to visualize the assets load below using https://www.npmjs.com/package/rollup-plugin-visualizer

This is the build output:

---

Also I had to give node more memory in AWS code build, otherwise it ran out of memory.

I suspect if we removed the Water Management components/hooks/etc, we might see a slim down. Maybe they should go in a separate npm package?

cc @willbreitkreutz

[adamscarberry]

I ran the same tool on the groundwork lib:

[adamscarberry]

I ripped out plotly locally only just to see what would be left:

---

So it looks like plotly is the pig.

[willbreitkreutz]

@adamscarberry thanks for looking at that, it doesn't surprise me that plotly would be the pig. Might break out groundwork-water groundwork-plots with the existing groundwork-geo

[krowvin]

Throwing my $0.02 in the ring

Maybe they should go in a separate npm package

groundwork-water

The timing is wild here.
I have been thinking district specific components might be better suited in a mono repo here.
The ../usace-watermanagement repo.

And then any components that would be maintained by GroundWork could be bubbled up to that level.
This makes it easier for any given district to maintain their own components.

Alternatively, if groundwork wanted to use those templates it could call them as dependencies instead of assuming control (and maintenance) of them.

Then as you mention

a separate npm package

Either per district or for the whole repo. I.e. a sep NPM project within each directory of a mono repo.

For example

/usace-watermanagement/groundwork/swt/components/DroughtMap.jsx
/usace-watermanagement/groundwork/swt/package.json

And summoning a few others for this - as it seems like a larger decision

@MikeNeilson @DanielTOsborne @jbkolze @JeremyDKellett

Edit:

/usace-watermanagement/groundwork could be confusing.
Perhaps groundwork-water as Will mentions, but in this repo org.

[willbreitkreutz]

I'm curious what others think, but I would caution against flaking out into lots of district based packages. I think groundwork-water makes sense, any sharable components districts develop should be contributed there, any more generic components would be contributed to groundwork proper. Any components that are specific enough that they would only be used by one district would just live in that separate consumer application.

[MikeNeilson]

I'm going to, i think, agree with Will here. While there is certainly a separation of concerns - not all districts water management mission is the same - but there are similarities, it likely makes more sense to just organize by concept vs district.

Maybe with some exceptions for some real doozy edge cases. (e.g. no one should do the rounding LRE is required to do "by law", except LRE of course.).

[MikeNeilson]

This is also starting new, the projects were I'm pushing "here's a separate place for district stuff" is because I'm pretty sure it'll be an easier transition.

[jbkolze]

If we're separating repos, I think it probably does make sense that groundwork-water be hosted within the WM org. I see base groundwork as the foundational design/layout components, with any offshoots of that applying the design for org-specific purposes / components. Seems to follow that the org would be the owners/stewards of that part of it.

I do think it will be important to ensure that layout-focused changes/enhancements that aren't org-specific get rolled up into base groundwork. It will be a lot easier to lose sight of that if repos are separate, and one of the main points is to keep design aspects as similar across-the-board as is feasible.

Agree that managing all district-specific components in one repo could get messy, and that those are probably best stored in their dependent applications (or potentially in a district-owned repo if used in a variety of apps).

[krowvin]

I'm curious what others think, but I would caution against flaking out into lots of district based packages. I think groundwork-water makes sense, any sharable components districts develop should be contributed there, any more generic components would be contributed to groundwork proper. Any components that are specific enough that they would only be used by one district would just live in that separate consumer application.

Well this makes sense to me! I think Will irons it out well here too.

So Then If I follow:

• If it's generic it goes in usace/groundwork
• If it is WM but not district specific it goes in usace-watermanagement/groundwork-water
• If it is WM and district specific it goes in a given district's org (ideally)?