Support multiple profiles in copy task

[Marc Jansing]

Hi @aj-foster, i really like this package. I want to use this package to copy multiple npm managed fontsource font files into priv/static/fonts. My current configuration looks like this:

config :phoenix_copy,
       font_roboto: [
          source: Path.expand("../assets/node_modules/@fontsource/roboto/files", __DIR__),
          destination: Path.expand("../priv/static/fonts/roboto", __DIR__)
       ],
       font_opensans: [
         source: Path.expand("../assets/node_modules/@fontsource/open-sans/files", __DIR__),
         destination: Path.expand("../priv/static/fonts/open-sans", __DIR__)
       ]

To copy those assets I have to invoke two copy task and even specify two file watchers:

# mix.exs
"assets.deploy": [
  "phx.copy font_roboto", 
  "phx.copy font_opensans",
  "esbuild default --minify",
  "sass default --no-source-map --style=compressed --load-path components --load-path node_modules",
  "phx.digest"
]

# dev.exs
watchers: [
  font_roboto: { Phoenix.Copy, :watch, [:font_roboto] },
  font_opensans: { Phoenix.Copy, :watch, [:font_opensans] },
  ...
]

It would be great if copy task allows supplying multiple profiles (font_roboto, font_opensans in my case).

Another and in my opinion better way solve this issue would be the possibility to specify multiple source/destination pairs in the same copy profile. Then it would be possible to specify a generic font-profile with multiple font declarations. Dartsass also uses this approach:

config :dart_sass,
       version: "1.44.0",
       default: [
         args: [
           "scss/index.scss:../priv/static/assets/app.css",
           "scss/map.scss:../priv/static/assets/map.css",
           "scss/azure-map.scss:../priv/static/assets/azure-map.css"
         ],
         cd: Path.expand("../assets", __DIR__)
       ]

What do you think?

[AJ Foster]

Hi @mjansing, thanks for opening this issue.

I agree, supporting multiple profiles in a single call is a great idea. Version 0.1.1 — just published — adds support for this behavior.

Please let me know if you have any feedback on this update!

---

The configuration for dart_sass is interesting. I like the concise way of expressing the source and destination pairs. Just thinking aloud, we'd have to parse the paths carefully. Using Path.type/1 we could determine whether the path is expanded already. Not immediately sure how to handle non-expanded paths in the case that the configuration is being read in a release environment, but we can investigate further.

We can probably support this without breaking compatibility, and mark the source/destination keyword list as deprecated for removal in a 1.0.0 release.

[Marc Jansing]

Hi @aj-foster,

thank you for your quick response and Version 0.1.1. I'll take a look at it.

The configuration for dart_sass is interesting

I'm not really sure if this inline sting notation is the best way to solve this issue, but I like the possibility to specify multiple file/destination pairs in a single semantic profile (e.g. fonts in my case).

I think it would be better to use elixir types:

config :phoenix_copy,
        fonts: [
          %{
            source: Path.expand("../assets/node_modules/@fontsource/roboto/files", __DIR__),
            destination: Path.expand("../priv/static/fonts/roboto", __DIR__)
          },
          %{
            source: Path.expand("../assets/node_modules/@fontsource/open-sans/files", __DIR__),
            destination: Path.expand("../priv/static/fonts/open-sans", __DIR__)
          }
        ]
´´´