LG-11001: Mark i18n as peerDependency in certain @18f/identity- packages

[allthesignals]

🎫 Ticket

🛠 Summary of changes

It makes i18n a peer dependency and prevents duplicate copies by configuring Webpack to exclude it during the build.

I marked the affected packages as a major version bump because it would be breaking.

📜 Testing Plan

I've spot-checked this in the individual builds and identity-site, and found only one copy.

I sanity-checked this by seeing how many copies were included in the build output before these changes. There were 2 extra copies!

[allthesignals]

I don't really love the way this is set up... we would need to get Webpack to distinguish between packages that are available via workspaces and packages that are published on the npm registry. Otherwise, we are left explicitly specifying this....

[gina-yamada]

App working as expected. A 'requires' list added to the components README would be nice, but non-blocking. Good idea bumping up to major version b/c of breaking change. LGTM- approving

[aduth]

I wonder -- could it work to just mark the package as an external and list it as a dependency rather than a peer dependency? If the goal is to avoid bundling it in the built output, I think that should suffice, and makes it easier for the downstream consumer vs. separately installing the i18n package?

[allthesignals]

I wonder -- could it work to just mark the package as an external and list it as a dependency rather than a peer dependency? If the goal is to avoid bundling it in the built output, I think that should suffice, and makes it easier for the downstream consumer vs. separately installing the i18n package?

Oh, yeah, let me try that.

(For my own understanding:) IIRC we moved react/react-dom to peer dependencies because react itself is pretty strict about which copy of react is imported and used to render...? I'm a little fuzzy on the reasoning. Like, the consumer has to import react to render, and we need our library to reference that same copy. (The alternative, letting it implicitly load as a regular dependency, wouldn't allow us to import react consumer-side at all... but then why can't npm/yarn resolve this correctly to only use one copy? Brushing up here).

[aduth]

Yeah, that's a good question. I think in that case it has a lot to do with the downstream project also needing to use a React dependency, so I suppose similar logic could apply for i18n if we're expecting to use it directly in identity-site.

It gets more fuzzy since in either case Webpack or whatever bundler should be deduplicating regardless. 🤷

[allthesignals]

Yeah, that's a good question. I think in that case it has a lot to do with the downstream project also needing to use a React dependency, so I suppose similar logic could apply for i18n if we're expecting to use it directly in identity-site.

Yeah, actually, I was about to say... we do directly import and use i18n on identity-site, and they need to be the same copy. So, I don't think we can get away with having it listed as a regular dependency.

It gets more fuzzy since in either case Webpack or whatever bundler should be deduplicating regardless. 🤷

Right, it's weird Webpack wasn't doing that. It included 3 copies instead of 1! Maybe that has to do with how the externals feature works.

[aduth]

Given prior discussion, I think this works as-is 👍