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

Support hashed production filenames #2

Closed
kadamwhite opened this issue Apr 19, 2019 · 5 comments
Closed

Support hashed production filenames #2

kadamwhite opened this issue Apr 19, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@kadamwhite
Copy link
Collaborator

Currently the way we match files on disk is by direct filename match, e.g. theme.js. This breaks down if the Webpack config specifies a hashed value in the output filename. We should support loading hashed files in production mode, or clarify explicitly that it is prohibited if it becomes too complex.

@goldenapples
Copy link
Contributor

To this end, I'd like to be able to pass an array of manifests to Asset_Loader\enqueue_asset, and have the asset loader use the first found manifest of the list.

This would be useful in cases where assets should be served from a dev manifest if one is found, and from a prod manifest if the dev server isn't running.

@kadamwhite
Copy link
Collaborator Author

@goldenapples if both asset manifests share a file name, asset-loader should behave as expected currently. (This is admittedly undocumented, and makes certain other assumptions). Is the desire for multiple manifests a hard requirement?

@goldenapples
Copy link
Contributor

goldenapples commented Oct 21, 2020

Is the desire for multiple manifests a hard requirement?

No, other than the fact that it would be nice if the site could load from the dev manifest while the dev server was running, and then fall right back to the prod manifest if not. (Since the dev manifest is usually cleaned on exit, having it at the same file path as the prod manifest would mean overwriting and wiping out the prod manifest when the dev server is started and stopped.

As I looked through other open issues, I actually prefer the suggestion you made in #21 (comment):

	AssetLoader\enqueue_asset(
		manifest_file_path(),
		'propose-draft-date.js',
		[
			'handle'  => EDITOR_BUNDLE_HANDLE,
			'scripts' => [
				'wp-components',
				'wp-i18n',
				'wp-date',
				'wp-data',
				'wp-edit-post',
			],
		]
	);

and letting the manifest_file_path() function could be responsible for choosing which manifest to load.

My stab at this (in a locked repo, sorry) currently just checks for manifests like this:

	// The 'asset-manifest.json' file should only be available if the dev server is running.
	$is_dev = Manifest\load_asset_manifest( dirname( __DIR__ ) . '/build/asset-manifest.json' );

	Asset_Loader\enqueue_asset(
		dirname( __DIR__ ) . '/build/' . ( $is_dev ? 'asset-manifest.json' : 'prod-asset-manifest.json' ),
		'editor.js'
         );

...which is clean enough for me. But it might be nice to provide a helper function that, given an array of manifest files, returns the first one that exists and is readable?

@kadamwhite
Copy link
Collaborator Author

I can absolutely get behind a helper function, thanks for that suggestion

Thinking through what this would look like: is_readable should suffice for a performant check, we can iterate through an array of string paths and return the first readable match. I can take a crack at that in a week or so's time, otherwise happy to review a PR if you have the inclination in the interim!

@kadamwhite
Copy link
Collaborator Author

This has been resolved since the issue was first opened.

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

No branches or pull requests

2 participants