WIP: ease usage with ember-cli-content-security-policy

[jelhan]

Currently all users of Ember CLI Content Security Policy must explicitly set forbidEval to true in Ember Auto Import's configuration. Unless the very rare case that they allow "unsafe-eval" in style-src directive.

This is disruptive for users of both sides. Since Ember CLI blueprints for new application includes Ember Auto Import and many addons depend on it as well nearly all user of Ember CLI Content Security Policy must set that configuration. It does not help with adoption of CSP or testing for CSP compliance in Ember ecosystem.

This pull request propose to change the default value to depend on the presence of ember-cli-content-security-policy depenendency. If the application depends on ember-cli-content-security-policy forbidEval defaults to true. Otherwise it is false.

I would not consider this as a breaking change. At least I'm not aware of a meaningful use case to not having forbidEval set to true if CSP is used.

[jelhan]

Not fully sure why dependencySatisfies macro from @embroider/macros fails. But before digging deeper into it I would appreciate some feedback if you are open to accept such a change.

[ef4]

Thanks, I like this.

dependencySatisfies only asks about your own dependencies, because you can only reliably access your own dependencies (without depending on accidental implementation details that we don't want to lock in forever).

In a case like this one, ember-auto-import can declare an optional peer dependency on ember-cli-content-security-policy. The benefit of requiring this is that it makes it clear to package managers that you want access to the same copy of that library that is present in your parent package, if it happens to be there.

[jelhan]

I added ember-cli-content-security-policy as an optional peer dependency in 29d4183. But tests are still failing. Not sure if I done something wrong. But I'm wondering if @embroider/macros babel plugin is running at all. I would have expected it to fail when running the babel plugin. And not silently skipping the code and than throwing at execution time.

I can refactor to classical methods to determine if the consuming application has the dependency. I was mostly using @embroider/macros to demonstrate the concept. Haven't checked if this specific usage is supported at all, if targeted Ember versions are matching, etc.

[jelhan]

@ef4 Would it be an acceptable path forward for you to not use @embroider/macros but a classic strategy like ember-cli-version-checker?

[ef4]

We don't want this to ever return true when this.isAddon is true, because addons don't get to decide this. Only the Package instance representing the app should decide to maybe return true.

I think the difficulty you're having with @embroider/macros is that they're designed to go in runtime code, not node code. This is node code. Instead, take a look in this same file where we're checking the version of ember-source that the app is using. You can check whether the app is using ember-cli-content-security-policy the same way.