Create empty file when not found

[vongohren]

I wonder about one thing. I found that this service expects it to exist a file in the storage location for it to work? Is that correct? Or is it something I have done wrong?

The problem with this is when initiating the infrastructure, it is unclear who shall controll this empty state. Setting up with terraform and creating a file a provision is not optimal, as the terraform state changes and the file is not consistent. So I do believe this service should handle empty bucket, and potentially just create an empty file.

But maybe it already does, and I had the wrong setup when testing out?

[joeldenning]

import-map-deployer currently will create an empty import map if the io-method's readManifest function returns an empty string. See the code below:

import-map-deployer/src/modify.js

Lines 50 to 51 in 3c947e2

	if (data === "") {
	json = getEmptyManifest();

Currently the in-memory io-method (used mostly for tests) will return an empty string from readManifest when it's starting out, but no other io-methods do. What this means is that currently the import map file must be created by something other than import-map-deployer, but its contents may be an empty string.

I agree that it'd be nice change import-map-deployer so that it upserts an import map when you read/modify the map. I think the best way to do that would maybe be to have the readManifest function in each io-method catch any errors and check if the object key doesn't exist versus other errors? And if the key doesn't exist, create it with an empty import map. I find that to be a bit better than having it return an empty string, as then GET /import-map.json would return an empty import map even though the file doesn't yet exist in s3/azure/gcp storage. What do you think?

[vongohren]

@joeldenning yeah that does seem like a nice solution. As the error is thrown from this service when there is nothing to find.

I will see if I can get to this within a week or so, but no promises. If anyone else does find the time to do this before, its probably a better bet

[joeldenning]

Do you have interest in submitting a pull request implementing this?

[vongohren]

@joeldenning its on the list of things I have left of my current job. But not highest on the list right now. So that is why I said not to promise anything and it may take some time. But I like this tool so it might be time until it is in

[tungurlakachakcak]

Do you have interest in submitting a pull request implementing this?

Hello, @joeldenning ! :) Long time no write!
I came across this issue, because I have a similar use-case, maybe I could help.
My use-case is that there are a lot of environments and I do not want to manually set up this file in each S3 bucket.
So we will be creating a new manifest in S3 if there is nothing there, right? In a nutshell?

Of course, if @vongohren does not mind and he is not currently working on this.

[vongohren]

@quenchaman @joeldenning yeah I have not been able to get to it, but yeah, basically create an empty manifest in the bucket of choice. Not just s3 :P
So putting it at a layer that handles all supported buckets

[tungurlakachakcak]

Making it work for all buckets in a higher level of abstraction is like playing twister with an octopus..
I think that we cannot get around checking what the error is before doing anything and every bucket provider has different error codes and messages. io-operations.js -> readManifest is a good candidate for such code.
But I would personally go with defining the logic for each persistance type separately, for simplicity.

[vongohren]

@quenchaman sounds smart. But how about putting it at the right abstraction level, and letting the different bucket types hold the error handling so you atleats put it in the right place? If that makes sense?

I dont remember if there is class abstractions or anything there, but when then read manifest would fail, one can call this.handleError? Or do a switch case with a default action of file creation is not implemented for this bucket?

[tungurlakachakcak]

I do not think that putting the checks in a centralised place is a good idea and with the current error handling it would be a nightmare.
Yes, you would handle it "in one place", but that can't be in a polymorphic way.
At least that's my engineering view of it.

[vongohren]

Its a long time since I have been in the code base, so unsure, I guess it was my hope that getManifest was agnostic of what bucket called it, so that it could just handle and error where the bucket implementation would take over.

[joeldenning]

#107 implemented this for s3 and is released in https://github.com/single-spa/import-map-deployer/releases/tag/v4.1.0. This still needs to be implemented for the other providers, so I'm keeping this issue open to track it for them.

[joeldenning]

Azure support in #109, but reopening for the remaining io methods

[joeldenning]

The import map should be automatically created if it's not present, when using s3 or azure. The other IO methods don't have this implemented yet. Which IO method are you using?