You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@adamscarberry thanks for looking at that, it doesn't surprise me that plotly would be the pig. Might break out groundwork-watergroundwork-plots with the existing groundwork-geo
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.
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.
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.).
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.
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).
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)?
Activity
adamscarberry commentedon May 7, 2024
I ran the same tool on the groundwork lib:
adamscarberry commentedon May 7, 2024
I ripped out plotly locally only just to see what would be left:
So it looks like plotly is the pig.
willbreitkreutz commentedon May 7, 2024
@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-geokrowvin commentedon May 7, 2024
Throwing my $0.02 in the ring
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
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.Perhaps
groundwork-wateras Will mentions, but in thisrepoorg.willbreitkreutz commentedon May 7, 2024
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.MikeNeilson commentedon May 7, 2024
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 commentedon May 7, 2024
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 commentedon May 7, 2024
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 commentedon May 7, 2024
Well this makes sense to me! I think Will irons it out well here too.
So Then If I follow:
usace/groundworkusace-watermanagement/groundwork-water