support being able to specify the path to the .discharge.json file

[fragosti]

It would be handy to have multiple .discharge.json files per project, and then choose which to use for the deploy command.

[brandonweiss]

👋

What’s the use-case for having multiple configurations for the same project?

[fragosti]

In the short term, we'd like to have a "staging" and "dogfood" bucket. In the longer term, we'd like to have a static deployment per branch. So basically the use-case is different environments / builds being deployed to different buckets.

[brandonweiss]

Hmm. 🤔 I’m going to walk through a few scenarios/solutions I see.

There’s a scenario where someone might want two or more separate configurations. In theory they could change the configuration in some way to see how it affects deployment on a staging bucket. And then if the change was desirable, presumably it would be mirrored to the production configuration and then the two configurations would be identical, except for the bucket name. And there are only so many configuration options and ways to change them. Having two separate configurations seems overly-complex.

There’s a scenario where there is one configuration, but you want to dynamically change the bucket name. Maybe it defaults to the “production” name but you can override it via the command line when deploying to the “staging” bucket. The ergonomics of that feel a little weird though. Specifying an option one way and overriding it another way is confusing. Perhaps the bucket name shouldn’t be in the configuration file at all and should only be specified via a command line argument. That’s clearer, but then that optimizes the ergonomics for people who want to deploy to multiple buckets, which so far seems like a bit of an edge case.

The last scenario is where someone just manually changes the bucket name if they want to deploy to a staging bucket to test something out. That’s not great if you’re working with more than one person because then the name of the “staging” bucket isn’t defined anywhere and someone might call it one thing someone else might call it another. But, buckets are cheap and it probably doesn’t matter that much if someone unintentionally creates a third staging bucket because they called it “test” instead of “staging” or something.

---

My tendency is to ruthlessly avoid complexity whenever possible. I’ve personally only needed to “test” something once and I just renamed the bucket temporarily when I did that. My gut tells me that the ability to change bucket names or configuration files dynamically isn’t something that would be widely-used. Discharge is a relatively simple tool meant for relatively simple uses. The concept of “environments” is something I would generally associate with more advanced needs, like running a serious application. While it’s entirely possible someone could deploy a serious single-page application with Discharge, I think they would quickly outgrow Discharge and/or being able to host it on S3—neither are really designed for that use-case.

If I’ve misunderstood or missed a common use-case, please let me know! Otherwise, I’ll leave this issue open for awhile to see if anyone else has this problem and wants to chime in.

Thanks!

[fragosti]

@brandonweiss it seems that all your scenarios assume that the goal long-term is to have one bucket / configuration, or to quickly test changes in a different bucket.

What I'd like is to have two different configuration files at all times, such to enable features like yarn deploy-dogfood and yarn deploy-staging. In our case, we may have slightly different bundles and slightly different index.html files we'd like to deploy to different buckets.

The complexity of this addition is basically negligible. It allows you to configure something that before was just a constant. Fortunately, the code is already written to handle this pretty well. It works the same by default. #71

I think S3 + Cloudfront is a perfectly reasonable place to host a front-end application.

[brandonweiss]

Ah, sorry, I think I understand your scenario now!

When I think about complexity I’m not just talking about the code—in this case the code is negligible. The complexity I’m more concerned about is conceptual. We would have to explain that this feature exists, why it exists, and how to use it. That on its own might not be that much complexity, but it adds to the complexity that already exists in multiplicative way, making the tool more complicated to understand.

My gut still says this is a scenario that is going to be pretty rare for most people using Discharge, which makes it difficult to justify the additional complexity at the moment.

Here’s how I would work around it for now. Create two configuration files, maybe .staging.json and .production.json. Then your deploy-staging script could be:

cp .staging.json .discharge.json && discharge deploy && rm .discharge.json

And then your deploy-production script would be:

cp .production.json .discharge.json && discharge deploy && rm .discharge.json

I think that would let you do what you want to do?

[fragosti]

@brandonweiss yes that is a good workaround. However, I've just resolved to point to my fork for now :) (if you are curious: https://github.com/0xProject/0x-monorepo/pull/1210/files)

I think the feature can simply be explained as "ability to change the name of the config file". While I still think this change is a worthwhile addition, I understand your desire to keep it out! I guess we will see if other people request this feature, and in the meantime I will use my fork.

Thanks for making such a great CLI tool! It's my go-to for quickly deploying static sites.

[brandonweiss]

@fragosti Sounds good!

You’re very welcome! ❤️