Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple entrypoints, manifest.json, entrypoints.json and encore_entry_script_tags() #92

Open
plashenkov opened this issue May 14, 2020 · 1 comment

Comments

@plashenkov
Copy link

plashenkov commented May 14, 2020

Hi!

I am trying to use multiple Webpack configs in my webpack.config.json. Following this guide — https://symfony.com/doc/current/frontend/encore/advanced-config.html — I've specified all builds inside webpack_encore.yaml. And then I've tried to output my script(s) in my Twig template:

{{ encore_entry_script_tags('entry', null, 'build_name') }}

But I've got the following error:

An exception has been thrown during the rendering of a template ("Asset manifest file "/[path]/public/build/manifest.json" does not exist.").

Okay... but there is nothing about that neither in the docs nor in the webpack_encore.yaml.

After some digging I've found assets.yaml and that disabling assets.json_manifest_path solves this issue and everything renders.

But I am still not sure — I do everything correctly or not. Maybe I have to specify builds (which are named "packages") inside assets.yaml as well? And then:

{{ encore_entry_script_tags('entry', 'build_name', 'build_name') }}

But... I have to repeat the same parameter twice for some reason. And I have to specify my Webpack builds in several config files (under different keys).

It looks absolutely unintuitive. And there is a lack of information in the documentation about this.

P.S. I've found this: https://symfony.com/doc/current/frontend/encore/versioning.html

The first file - entrypoints.json - is used by the encore_entry_script_tags() and encore_entry_link_tags() Twig helpers.

The manifest.json file is only needed to get the versioned filename of other files [...] Be sure to wrap each path in the Twig asset() function like normal

I.e. entrypoints.json for encore_entry_script_tags(), and manifest.json for asset()? But I still do not understand why encore_entry_script_tags() needs both parameters. If we can disable assets.json_manifest_path in assets.yaml and everything seems to work without it why does encore_entry_script_tags() depend on both parameters? Why can't we make encore_entry_script_tags() and asset() dependent on the same unified parameter?

P.P.S. Honestly, in ideal world it would be great to specify builds only inside webpack.config.json and then just use them in encore_entry_script_tags() without adding them manually in several configs.


Summarizing:

  1. Using multiple builds looks confusing now.
  2. Following documentation doesn't give us working result.
  3. Lack of info why everything is as it is.

Thank you! :)

@plashenkov
Copy link
Author

plashenkov commented May 16, 2020

Hey,

Since Encore build produces manifest.json, and manifest.json is a package's attribute, an Encore build and assets package are actually the same thing. Now, in current implementation, they are separated, but logically they are the one thing. Or I'm wrong?

Encore (or Encore-less webpack, or other bundlers) builds completely fit into the concept of asset packages.

But it looks like for now, they are separated, and this is not very correct. Historically there were assets with their packages. Later Encore has appeared, and it has brought its own separate config with builds and other options. And now we have two concepts instead of, actually, one: packages and builds. And this gives us confusion. We have encore_entry_script_tags() and encore_entry_link_tags() with two parameters instead of one, etc. In this case maybe we should think about how to gracefully merge these two separated concepts into one.

Or maybe everything currently is really as it should be? And is not subject of change in future version?

P.S. I've found this comment as well: #17 (comment)

Later @shulard answers that packages and builds are different things, but... Yes, now they are separated. But should they really be? This is really confusing now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant