Add support for keeping public assets and ember-addon.public-assets meta in sync

[phndiaye]

While migrating an addon to the v2 format, I noticed that we need to declare the files from the public directory in the ember-addon.public-assets meta in the package.json, which is easy if there isn't much of them, but can get out of hand quickly (I have a couple addons providing a lot of assets to the parent app)

This adds support for keeping an addon's package.json ember-addon.public-assets meta in sync with the public directory by default.

By passing opts.exclude (glob pattern array), you can still ignore some of the files if needed.

export default {
  output: addon.output(),

  plugins: [
    addon.publicEntrypoints([]),

   // Other plugins declared in the samples

    addon.publicAssets('assets'), // Or addon.publicAssets('assets', { include: ['**/*.svg'], exclude: ['**/*.png'] }) to skip all PNG files and include SVG ones
  ]
};

[phndiaye]

To my knowledge, the public folder is not something that's configurable. Otherwise, this could be part of the options (w/ a default value)

[simonihmig]

I don't think there is any specific path mandated here, according to https://rfcs.emberjs.com/id/0507-embroider-v2-package-format#assets. Also this is about the v2 addon's internal file layout, and that should be seen as an implementation detail.

So I would suggest to make this configurable. Also, maybe we should also have an include pattern that we can pass to glob of walkSync? So users could say e.g. publicAssets({ path: 'assets', include: '**/*.svg'), to make all svgs in ./assets (instead of ./public).

[simonihmig]

I think that's a good feature to have!

Although the public folder is IMHO a bit of a remnant of the old (push-based) world. We might instead recommend people to the pull-based world in the future, when we have a default setup for importing static assets (related: #1323, emberjs/rfcs#763). But as we have that feature currently, we can also make it more ergonomic for sure...

[simonihmig]

nitpick: I wouldn't call it (re)exports, as this is not getting imported. Rather it's more of the classic push models vs. pull. Maybe just name it just similar to the public API for users, like rollup-public-assets?

[simonihmig]

I don't think there is any specific path mandated here, according to https://rfcs.emberjs.com/id/0507-embroider-v2-package-format#assets. Also this is about the v2 addon's internal file layout, and that should be seen as an implementation detail.

So I would suggest to make this configurable. Also, maybe we should also have an include pattern that we can pass to glob of walkSync? So users could say e.g. publicAssets({ path: 'assets', include: '**/*.svg'), to make all svgs in ./assets (instead of ./public).

[ef4]

This seems good and I agree with Simon's feedback.

The one thing I'll point out is that we hope to not make addons use this for most cases. It's actually pretty problematic if addons are putting things in here that the addon plans to access at runtime, because the connection between the consumption site and the asset is not statically visible. It means that people run into trouble when they deploy assets to a CDN or adjust fingerprinting rules, etc, because the arbitrary runtime code needs to know about those changes.

We want to instead allow code to explicitly ask for an asset's URL. In embroider apps today people often use the native webpack 5 asset handling to import the URL of an asset:

import iconURL as "./icon.png";

And that works well but it's not really a standard and we'd like to come up with something less implementation-specific. I'm hoping the import assertions spec proposal actually moves forward again at TC39, because that would create a web-standards-compliant way to do this.

[phndiaye]

@simonihmig @ef4 Thanks for the review and comments!

I agree the public folder naming here reminds of the older way so I was wondering if it was worth defining it as a default value in the implementation or if we should "force" users to provide a value for it. This would lead to a signature like:

publicAssets(path: string, opts: { include: string[], exclude: string[] })

@ef4 Indeed this should be avoided as much as possible as it kind of negate the work done to make things statically analysable. But there are cases where I find it really useful, for example when implementing a design system and you need to provide all parents apps some branding assets (or when converting existing apps that are not importing assets in JS yet)

Do you think it can be added and documented somehow but not put in the sample Rollup config as it's not the recommended way?

[ef4]

Even for shared branding assets I think we'd want people to use "the new way". Meaning, users of your addon can either import the assets directly out of the addon, or the addon can provide components that directly import the assets.

But yeah, since there's no standardized "new way" right now I'm fine with moving forward this PR. It can be a documented option that's not enabled by default.

[phndiaye]

I see... I still have to shape my mental model around this "new way" but I will keep that in mind as I move more addons to the v2 format.

Updated the PR to reflect the feedbacks, by the way.

[phndiaye]

Looks like the CI is failing w/ this issue #1366 :/