Future of @spectrum-web-components/bundle

[Westbrook]

There have been some requests around changes and expansions to the @spectrum-web-components/bundle to better support installing SWC packages in a project. Please share any context, desires, proposals, or questions you might have in this area here so we can begin to develop an RFC for the next version of this package.

[Westbrook]

cc: @Aleodor-Tabarcea would love to hear your thoughts here!

[saigorantla]

@Westbrook, here are my thoughts.

We have a mono repo that contains a lot of package JSON files that import a few different spectrum components.
Rush is used to maintain the same dependency version across the repo.
To consistently maintain/ upgrade spectrum versions, it's hard to modify 20 different package JSON files.
If we have one spectrum library version, we can add to package JSON, reducing how many linens we are trying to upgrade. We can leave Webpack to remove all unnecessary code from dependencies and bundle necessary pieces.

[Westbrook]

How does you package manager do with resolving packages that are not in the individual packages in your project? E.G. I know that "yarn 1" will allow you to access packages no matter where they are depended on, but "yarn modern" will not. I'm not 100% sure about other contexts, but if you context is more like "yarn modern" then you'll continue to have 20 different package JSON files that you'll need to update when accepting an update. If your context is more like "yarn 1", then you can yolo this up, today!

In regards to tree shaking, for clarity, while tree shaking in a powerful tool in app performance management custom element definitions can't be tree shaken because they are important side effects, SWC lists them as such so that bundlers do not get greedy and toss out important code. That has little effect on how dependencies might be listed in package.json, but it does mean that even with a "better bundle" you'd still need to manage imports close to the same way they are imported in actual code today, regardless of the "package" from which you receive those imports.

With these things in mind, what do you think an alternate, more productive for you team, approach would actually look like in this area?

[moisadoru]

It would be nice to have a tool (web based or cli) to assist with specific SWC packages versions. You could create a collection of SWC packages from a list and the tool would generate the proper configuration (package + version). The tool could also read package.json (if cli) or a specific previously saved local storage config (if web based).

For monorepos (eg. managed by rush), a cli tool could parse all the package.json files, detect all the SWC dependencies and their versions, and provide options for upgrade (even a listing of upgrade-able packages would be nice). Even better, the tool could assist with on-demand upgrading of specific packages by listing the changes needed to be done to the other transient dependencies.

[Westbrook]

This is definitely a cool area on investigation! I know of teams that are already writing their own scripts (usually pretty short, actually) to do this today. One of the benefits on project local CLIs is they can know everything about how your project is structured and take that into account when deciding how to make updates. I worry that the complexities of supporting a mono-repo and a monolith across myriad package managers, repo structures, and environments would end up being a drag on project resources. However, I've also no put too much thought into it, so I may be making a mountain out of a mole hill.

Have you spent any time looking into a project local CLI for you team? What sort of capabilities might it have? Would it really benefit from anything more fine grained than "upgrade to latest"?

If you're interested I can point you to similar approaches to this in other projects.

[najikahalsema]

I wish it was clearer when consuming packages that there is a version update available for a package while running yarn. Version mismatch-related troubles happen to me often, and I get stuck either during yarning or during runtime with an error, usually related to iconography. This isn't really a clear indicator that something is wrong with my versions...

I think our version updating method could be improved, especially because of the tedium that comes with bumping numbers by one every time a release is done. That being said, I never consume the bundle and outside of having versions stay aligned, it seems like a heavy lift for what will most likely only be a few packages consumed in reality. I like what @moisadoru is suggesting, though I'm not super opinionated on the particulars. I think anything would be an improvement from what we currently have.