# sst

Derek Kershner

01/22/2022, 6:18 PM
Proposal for Dependencies @thdxr (cc: @Frank, @Adam Fanello) Problem: SST dictates the use of certain versions of commonly used packages (apollo, next, eslint, jest, ts-jest, etc.) This causes use cases with other versions or clashing packages to experience difficulty in troubleshooting with little recourse. Constraint: SST must have a simple getting started, which requires a batteries-included install. Proposed Solution: 1.
become packages with no dependencies. There is no downside to this as only
packages consume them. 2.
packages created alongside their current packages. These packages would be the exact same code as the current packages, but with no dependencies. 3. NON-lite
would install
, and also install all of the current dependencies. These packages would become an index file with
export * from lite
. Benefits: 1. Allows a path for users to have completely custom and advanced apps with no restrictions. 2. Non-breaking change. 3. During the yearly major-version update (for Jest, ESLint, Apollo, etc), the
packages would give
a way to support users who do not want to upgrade their support packages (which would be legacy at that point), but still want to have the newest features. Major version updates in those packages are frequently met with challenges, and large apps are likely to appreciate this in a major way. Cons: 1. A small amount of work up front. I would volunteer for this, as I have already spent more time troubleshooting dependencies than would be required to implement. 2. The contributing experience for Open Source Devs of SST would have one layer of abstraction to uncover (they would have to realize the lite packages contain the business logic). 3. It's possible, but unlikely, there might be cryptic errors for
users, if things like ESLint are missing, but linting is enabled. Alternatives: 1. Fork. This is essentially the reverse of above, but achieves the same goal. It is more work, and benefit 3 goes away (since it wouldn't be internal SST anymore).
may also need a bit of love, I dont believe this is open source.


01/22/2022, 6:39 PM
Nice writeup, let me digest this
I would maybe even push for your lite suggestion being the default we just need to discuss it internally because there was some back and forth about this in the past
I generally prefer templates to solve this problem vs auto including everything

Derek Kershner

01/22/2022, 6:42 PM
I am in 100% agreement, just trying to keep it non-breaking. If breaking is OK, I believe your path is superior.

Adam Fanello

01/23/2022, 7:38 PM
I don't fully follow because I haven't digested all the dependencies... but yes a core "SST only" version coupled with documentation updates on features that require additional installs makes sense. The current all-in package can be nothing more than a package.json that pulls everything in as dependencies. Is that the proposal? A more complex approach would actually pull SST code out along with their dependencies. Ex: install
if you want QueryQL support and that includes the Apollo dependency.

Derek Kershner

01/24/2022, 2:44 AM
@Adam Fanello, your interpretation is correct. For your piecemeal package idea, I think the split should happen by construct, not the dependencies of the construct, if SST headed that way. I.e.
Perhaps that is what you meant though. Either way, I'm trying my best to work with the decisions already made, and still allow advanced functionality and flexibility. I like all the thoughts I am hearing though.

Richard Simpson

01/24/2022, 3:43 AM
+1 to the above. SST today feels onerous to pull in, even if that tree it's pulling is providing a lot of value. Identifying which constructs and tools are adding the most (or at all) to that tree and allowing to opt into them would be great and also make package maintenance and security concerns much simpler.
I know some other JS tooling vendors (Vercel?) are even bundling, packaging, or internalizing their dependency tree to reduce this burden. Maybe something to consider for certain aspects of this?