Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[WIP] Document "framework.assets.json_manifest_path" option #8004

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

Conversation

robfrawley
Copy link
Contributor

@robfrawley robfrawley commented Jun 7, 2017

This pull request adds initial documentation for the newly introduced asset JSON manifest file path option: framework.assets.json_manifest_path. Resolves #7659.

For reference on this new configuration option, see symfony/symfony#22046 and symfony.com/blog/new-in-symfony-3-3-manifest-based-asset-versioning.

@robfrawley
Copy link
Contributor Author

robfrawley commented Jun 7, 2017

Looks like the automatic pull request builds are broken again. Can you provide the platform.sh build log? I'm not positive, but I suspect the build error is due to the invalid XML I found in multiple files.

For example, the controller/argument_value_resolver.rst file contains invalid XML, specifically the line <defaults autowire="true" ... />. There are other, similar, instances, as well.

Importantly, this also causes build failure when building the Symfony documentation locally, as well!


The ``json_manifest_path`` option was introduced in Symfony 3.3.

The file path to a `manifest.json` file containing an associative array of asset
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

two ticks around manifest.json here.. and 2 lines below


The file path to a `manifest.json` file containing an associative array of asset
names and their respective compiled names. A common cache-busting tecnique using
a `manifest.json` file works by writing out assets with a "hash" or "chunk hash"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove or "chunk hash" - it may just confuse people - the important thing is that it's some hash in the filename

The file path to a `manifest.json` file containing an associative array of asset
names and their respective compiled names. A common cache-busting tecnique using
a `manifest.json` file works by writing out assets with a "hash" or "chunk hash"
appendened to their file names. You can incorporate this into many workflows,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... file names (e.g. main.ae433f1cb.css).

names and their respective compiled names. A common cache-busting tecnique using
a `manifest.json` file works by writing out assets with a "hash" or "chunk hash"
appendened to their file names. You can incorporate this into many workflows,
including Webpack and Gulp using `gulp-rev`_ and `webpack-manifest-plugin`_,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

swap the order of the links to match the order before :)

framework:
assets:
# this manifest is applied to every asset (including packages)
json_manifest_path: "%kernel.root_dir%/../web/assets/manifest.json"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can now use %kernel.project_dir%/web :)


This parameter cannot be set at the same time as ``version`` or ``version_strategy``.
Additionally, parameter cannot be nullified at the package scope if a global manifest
file is specified.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additionally, this option cannot be...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a new sentence (probably not in the note, but at the bottom somewhere):

If an asset's path is not found in the manifest file, the original - unmodified - path will be used.

@weaverryan
Copy link
Member

@robfrawley Yea, the builds on platform.sh have been failing a bit more lately. Btw, we have invalid XML in controller/argument_value_resolver.rst? Can we fix it? And I'm curious why that's causing a failure in the build?

Anyways, THANKS for this PR - you're saving me time personally :).

Here are the failing build details: https://gist.github.com/weaverryan/cfd9db1da189bf6907a37c3fe436b106

Cheers!

@robfrawley robfrawley force-pushed the feature-document-framework-assets-json-manifest-path-option branch from 3b4dd0f to 74df78e Compare June 7, 2017 16:47
@robfrawley
Copy link
Contributor Author

robfrawley commented Jun 7, 2017

@weaverryan Thanks for the review; fixed all comments.

As for the build failures, it looks like the invalid XML is causing the highlighting subroutine to fail while it parses the XML. The build error you linked above is the same one I get locally. Here is the same failure with some additional context:

writing output... [ 38%] controller/argument_value_resolver                                                                                                                                                        
Exception occurred:
  File "/home/rmf/.local/lib/python2.7/site-packages/sphinx/highlighting.py", line 147, in highlight_block
    type='misc', subtype='highlighting_failure')
TypeError: warner() got an unexpected keyword argument 'type'
The full traceback has been saved in /tmp/sphinx-err-rIImIP.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
Makefile:45: recipe for target 'html' failed
make: *** [html] Error 1

Again, this is caused by the invalid XML line <defaults autowire="true" ... /> which I found in controller/argument_value_resolver.rst. Specifically, it looks #7883 caused a few of these errors.

@javiereguiluz No note added to https://symfony.com/doc/current/frontend/custom_version_strategy.html as the version strategy it describes is actually different from the json_manifest_path option.

@robfrawley robfrawley force-pushed the feature-document-framework-assets-json-manifest-path-option branch from 74df78e to b3c977e Compare June 7, 2017 20:36
@robfrawley
Copy link
Contributor Author

robfrawley commented Jun 7, 2017

There are a few other places in the documentation where asset versioning is briefly described, but these sections currently only mention the framework.assets.version option.

I've amended the documentation to include the new framework.assets.json_manifest_path option. Take a look at the diff below and let me know if you think I should include the changes in this pull request:

diff --git a/assetic/asset_management.rst b/assetic/asset_management.rst
index 4a78a7741..a1d58d468 100644
--- a/assetic/asset_management.rst
+++ b/assetic/asset_management.rst
@@ -552,10 +552,14 @@ done from the template and is relative to the public document root:
 
 .. note::
 
-    Symfony also contains a method for cache *busting*, where the final URL
-    generated by Assetic contains a query parameter that can be incremented
-    via configuration on each deployment. For more information, see the
-    :ref:`reference-framework-assets-version` configuration option.
+    Symfony also contains a few internal methods for cache *busting*. The
+    :ref:`reference-framework-assets-version` configuration option appends
+    a query parameter to the asset path that can be incremented manually
+    on each deploy in your configuration. The
+    :ref:`json_manifest_path <reference-assets-json-manifest-path>`
+    configuration option uuses a ``manifest.json`` file, generally created
+    using a Webpack, Gulp, or other asset work flow, that maps assets to
+    their respective compiled names.
 
 .. _assetic-dumping:
 
diff --git a/reference/twig_reference.rst b/reference/twig_reference.rst
index 86c8d5114..bebfbaabb 100644
--- a/reference/twig_reference.rst
+++ b/reference/twig_reference.rst
@@ -124,7 +124,10 @@ asset
 Returns a public path to ``path``, which takes into account the base path
 set for the package and the URL path. More information in
 :ref:`templating-assets`. For asset versioning, see
-:ref:`reference-framework-assets-version`.
+:ref:`reference-framework-assets-version`,
+:ref:`reference-assets-json-manifest-path`, and
+:ref:`reference-assets-version-strategy
+.
 
 assets_version
 ~~~~~~~~~~~~~~
diff --git a/templating.rst b/templating.rst
index 1a24325a0..7ccdc0b9c 100644
--- a/templating.rst
+++ b/templating.rst
@@ -774,10 +774,12 @@ should render with the subdirectory (e.g. ``/my_app/images/logo.png``). The
 being used and generating the correct paths accordingly.
 
 Additionally, if you use the ``asset()`` function, Symfony can automatically
-append a query string to your asset, in order to guarantee that updated static
-assets won't be loaded from cache after being deployed. For example, ``/images/logo.png`` might
-look like ``/images/logo.png?v2``. For more information, see the :ref:`reference-framework-assets-version`
-configuration option.
+implement cache busting strategies. The :ref:`reference-framework-assets-version`
+configuration option appends a query parameter to the asset path that can be
+incremented manually on each deploy in your configuration. The
+:ref:`json_manifest_path <reference-assets-json-manifest-path>` configuration
+option uses a ``manifest.json`` file, generally created using a Webpack, Gulp,
+or other asset work flow, that maps assets to their respective compiled names.
 
 If you need absolute URLs for assets, use the ``absolute_url()`` Twig function
 as follows:

@robfrawley robfrawley force-pushed the feature-document-framework-assets-json-manifest-path-option branch from b3c977e to 14c609b Compare June 17, 2017 06:52
@weaverryan
Copy link
Member

Yes to the adding the diffs you posted, but let's shorten them - we should most say "there is versioning" and link. I just want to avoid duplicating explanations

@robfrawley
Copy link
Contributor Author

robfrawley commented Jun 18, 2017

@weaverryan Just pushed a commit with the additional cache busting references tweaked to include the new json_manifest_path option in a more concise way than my original diff. Let me know if I should apply any additional changes (or if you'd like me to squash or otherwise perform any additional steps on my end).

@robfrawley robfrawley force-pushed the feature-document-framework-assets-json-manifest-path-option branch 2 times, most recently from 8e1fa07 to c8aa434 Compare June 18, 2017 06:22
xabbuh added a commit that referenced this pull request Jun 18, 2017
This PR was merged into the 3.3 branch.

Discussion
----------

Remove/update lines causing build failures

This pull request amends the invalid code blocks within the documentation to fix the build errors (both locally and on `platform.sh`). ~~Additionally, this normalizes the dependency installation and build calls executed by both `travis` and `platform.sh` so they both use the same environment to build the documentation. _This is important as currently, often one will fail while the other will succeed; this should not ever happen and they should both either fail or succeed._~~

See #8004 (comment) and #8004 (comment) for the origin story.

~~*Note: This should likely be applied to the `3.3` branch which is where the errors originate, will update the target branch once this is confirmed.*~~

Commits
-------

18ee5e2 fix invalid code lines and remove extra space
Copy link
Member

@javiereguiluz javiereguiluz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@robfrawley I like this contribution a lot. And the note about the different cache busting options is useful too. Thanks!

@xabbuh xabbuh added this to the 3.3 milestone Jun 18, 2017
names and their respective compiled names. A common cache-busting technique using
a ``manifest.json`` file works by writing out assets with a "hash" appended to their
file names (e.g. ``main.ae433f1cb.css``). You can incorporate this into many work
flows, including Webpack and Gulp using `webpack-manifest-plugin`_ and `gulp-rev`_,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@weaverryan @javiereguiluz Does Symfony Encore support cache busting using a manifest.json file and hashed file names? If so, should we add a reference to it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does: added a note about that in combination with references for straight-webpack and gulp.

@robfrawley robfrawley force-pushed the feature-document-framework-assets-json-manifest-path-option branch from c8aa434 to 08d2af6 Compare June 20, 2017 22:43
@robfrawley robfrawley force-pushed the feature-document-framework-assets-json-manifest-path-option branch from 08d2af6 to f7c7b56 Compare June 20, 2017 22:48
@robfrawley
Copy link
Contributor Author

Latest commit squashed three previous commits. The only change is the inclusion of information about using Webpack Encore to create manifest files; the prior text about using straight-webpack and gulp remains, as well. See the new tip box for the changes.

@xabbuh
Copy link
Member

xabbuh commented Jun 22, 2017

Thank you @robfrawley.

xabbuh added a commit that referenced this pull request Jun 22, 2017
…tion (robfrawley)

This PR was submitted for the master branch but it was merged into the 3.3 branch instead (closes #8004).

Discussion
----------

[WIP] Document "framework.assets.json_manifest_path" option

This pull request adds initial documentation for the newly introduced asset JSON manifest file path option: `framework.assets.json_manifest_path`. Resolves #7659.

For reference on this new configuration option, see symfony/symfony#22046 and [symfony.com/blog/new-in-symfony-3-3-manifest-based-asset-versioning](https://symfony.com/blog/new-in-symfony-3-3-manifest-based-asset-versioning).

Commits
-------

13a3070 document new framework.assets.json_manifest_path option
xabbuh added a commit that referenced this pull request Jun 22, 2017
@xabbuh xabbuh closed this Jun 22, 2017
weaverryan added a commit that referenced this pull request Jun 28, 2017
* 3.4:
  Fixes for #8084 thanks to Stof
  Tweaks thanks to Javier
  Use Twig's namespaced paths
  adding anotehr faq for old packages without a main script
  minor rewording
  [Encore] Adding more FAQs for #8072
  [Encore] Documenting addPlugin - see #8070
  Documenting (better) how to expose global variables - see #8071
  [Encore] Adding docs about deploying to a subdirectory - see #8069
  Adding docs about adding custom config - see #8067
  Add missing link to handlebars-loader
  Add docs for custom loaders
  [#8004] some minor tweaks
  document new framework.assets.json_manifest_path option
  Minor reword
  Clearify setup of basic auth for test environment
  Update workflow.rst
  rearrange how workflow events are presented
  adding note about extracting CSS
  Adding note about browserslist config
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants