Repository navigation
A2W gained weight after using Groundwork #59
Description
Activity
I ran the same tool on the groundwork lib:
I ripped out plotly locally only just to see what would be left:
So it looks like plotly is the pig.
@adamscarberry thanks for looking at that, it doesn't surprise me that plotly would be the pig. Might break out
groundwork-watergroundwork-plotswith the existinggroundwork-geoReacted by Adam ScarberryThrowing 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-watermanagementrepo.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.jsonAnd summoning a few others for this - as it seems like a larger decision
@MikeNeilson @DanielTOsborne @jbkolze @JeremyDKellett
Edit:
/usace-watermanagement/groundworkcould be confusing.
Perhapsgroundwork-wateras Will mentions, but in thisrepoorg.I'm curious what others think, but I would caution against flaking out into lots of district based packages. I think
groundwork-watermakes sense, any sharable components districts develop should be contributed there, any more generic components would be contributed togroundworkproper. Any components that are specific enough that they would only be used by one district would just live in that separate consumer application.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.).
Reacted by Charles GrahamThis 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.
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).
Reacted by Charles GrahamI'm curious what others think, but I would caution against flaking out into lots of district based packages. I think
groundwork-watermakes sense, any sharable components districts develop should be contributed there, any more generic components would be contributed togroundworkproper. 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)?
Reacted by Brandon Kolze- If it's generic it goes in
- locked and limited conversation to collaborators
on May 17, 2024
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