search

single-spa / import-map-deployer

A manifest deployment service for sofe/import maps
Apache License 2.0
191 stars 63 forks source link

Add ability to specify which import map to patch #148

Closed bhovhannes closed 1 year ago

bhovhannes commented 1 year ago

Hello, we are happy users of import-map-deployer. We have it configured to update an import map hosted in S3 bucket. Url is like s3://<something>/prod/import-map.json.

We are going to have a brand new product with its own import map. However duplicating all our AWS infrastructure for the new product seems to be an overkill. Instead, we'd like to make import-map-deployer to be able to update s3://<something>/prod/{productName}/import-map.json where productName we will send as in a request body for PATCH/import-map.json endpoint.

Is there any reason import-map-deployer does not currently allow to specify import map to update during PATCH operation?

I am ready to open a pull request implementing that feature, but first wanted to make sure it conforms to the vision of this project.

Thanks!

CC @joeldenning @TheMcMurder

TheMcMurder commented 1 year ago

Knowing what I know about the Adobe Workfront infrastructure why doesn't using the env flag work for you?

Did y'all change the implementation in a way that makes it so you can't use that flag to change a specific import map?

bhovhannes commented 1 year ago

Env flag will work, but it will require making changes in import-map-deployer config for each new product.

To be honest I discovered that flag after opening this issue. Making change for each new product is an acceptable tradeoff.

However, ability to specify import map during PATCH request will allow to make everything dynamic and that way we will not hardcode names of import maps. I wonder why import-map-deployer was not built that way and requires to list all import maps you work with in its config.

TheMcMurder commented 1 year ago

I wonder why import-map-deployer was not built that way and requires to list all import maps you work with in its config.

IIRC it's a combination of several assumptions and technical goals:

Technical goals

  1. Infrastructure as code - we wanted to make it so that infrastructure changes had a git history that could be tracked
  2. No required database - perhaps could've still been achieved with a dynamic configuration

Assumptions

  1. Infrequent launch of new products/import-maps - In our experience it's pretty infrequent to launch a new import-map.
  2. Explicitly named import maps would be easier to manage than dynamic ones where a typo could result in an orphaned import-map and it wouldn't be apparent for several update cycles.
bhovhannes commented 1 year ago

Thank makes sense. Thanks!