Add fileIgnorePattern option

[mydea]

What Changed & Why

This PR adds the option to specify fileIgnorePattern, to ignore certain files (like sw.js).

Usage:

s3: {
  // other configuration
  fileIgnorePattern: 'sw.js'
}

Related issues

This is an alternative solution for #97.

PR Checklist

• Add tests
• Add documentation
• Prefix documentation-only commits with [DOC]

[achambers]

Thanks for the contribution @mydea . I have the same reservation with this PR as I did with #97 and that is this:

This kind of breaks how deploy plugins config works. It is a feature of ember-cli-deploy that you can specify a config property as a function which will be evaluated at runtime with the current deploy context object passed in as an argument.

This PR introduces the concept of a "config property as a function" that performs in a fundamentally different way than the functions do for all other plugin configs and it's at odds with the config function convention that ember-cli-deploy employs.

Currently it's well documented that if you supply a function as a config property it behaves a certain way. To magically make an exception to this seems like it could be problematic.

What are your thoughts on this?

Also interested to hear from @lukemelia and @ghedamat too.

[mydea]

Well, I personally would find this the most simple, configurable solution. But of course, other approaches would also be fine. We could provide a map, but that might be much harder to do e.g. when using fingerprinted assets. Then again, for me the most pressing need for that is for the sw.js file, which I guess is a common use case. We could also provide a "no cache blacklist", e.g. a glob for files to set the caching to no-cache, like noCacheFilePattern: 'sw.js'. While that would be much less flexible, it would not require a function.

From my perspective, the primary goal should be to make this addon work nicely with service workers (=sw.js). I think allowing a function would provide the most flexibility, but am absolutely open for other solutions - I'd be glad to adjust the PR accordingly.

I also feel that the approach with fileIgnorePattern: 'sw.js', and providing two s3 deploy configs would work, but it feels kind of overkill to me. Then again, if that's what I need to do to get this to work, I'll gladly do it!

[achambers]

The key thing here is that ember-cli-deploy is built on the convention that you can either provide a value as a config property, or a function. If providing a function, one knows that they can expect that the function will be called with the current context object, followed by a pluginHelper object. To make an exception to this for one use case seems problematic to me.

The concept of aliasing plugins is the ember-cli-deploy convention for running the same plugin with different configs and the current recommended approach for this use case. Sure, it's a slight bit more code, but is that a problem? It's just come configuration.

I'm happy to continue to explore new avenues absolutely and let's continue this conversation if it's of interest to you, but I'm very hesitant to add one off exceptions to the core conventions ember-cli-deploy employs such as is proposed by this PR.

[mydea]

So, I'll adjust this PR to instead add a fileIgnorePattern configuration option?

[achambers]

So, I'll adjust this PR to instead add a fileIgnorePattern configuration option?

I'd be more than happy to merge that change, yep 😄

[mydea]

I have updated the PR accordingly!

[ghedamat]

thanks @mydea

I've not been in touch closely but I think it LGTM after the last update

wdyt @achambers ?

[mydea]

Any chance to get this merged? :)

[ghedamat]

Sorry @mydea ! we'll be on it shortly!

[ghedamat]

@mydea released [email protected]

let us know if it works for your needs!

[mydea]

Awesome, works for me, thank you!