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.

core

and

nextjs-lambda

become packages with no dependencies. There is no downside to this as only

SST

packages consume them. 2.

cli

and

resources

have

lite

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

cli

and

resources

would install

cli-lite

and

resources-lite

, 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

lite

packages would give

SST

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

lite

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).

Nice writeup, let me digest this

I am in 100% agreement, just trying to keep it non-breaking. If breaking is OK, I believe your path is superior.

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

@serverless-stack/queryql

if you want QueryQL support and that includes the Apollo dependency.

@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.

@serverless-stack/construct-nextjssite

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.

+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.