#65452 (Twenty Nineteen: PostCSS configuration file never applies `autoprefixer`) – WordPress Trac

This ticket was mentioned in PR #12157 on WordPress/wordpress-develop by @desrosj.

6 weeks ago #1

This combines the two module.exports assignments to ensure that all desired plugins are run.

Trac ticket: Core-65452.

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 4.7
Used for: PR created with Claude and reviewed by me.

#2 @desrosj
5 weeks ago

Owner set to desrosj
Resolution → fixed
Status new → closed

In 62510:

Twenty Nineteen: Ensure only one PostCSS module is configured.

The postcss.config.js file in Twenty Ninteen currently has two module.exports asignments configuring two plugins: autoprefixer (for ensuring browser-specific CSS nuances are accounted for) and postcss-focus-within (ensures :fucs-within rules are duplicated as [focus-within] attribute selectors).

The first assignment is being ignored entirely, which means autoprefixer never runs against generated CSS files.

This updates the postcss.config.js file to contain only one modules.export statement, which restores the behavior of autoprefixer. The dependencies related to browser usage statistics have also been updated, and the resulting changes to built CSS files subject to version control are also included:

Browser-specific prefixes for the hyphens property have been removed.
The ::-moz-selection is no longer required for the ::selection psuedo-element.
Brower-specific prefixes are no longer required for min-content and max-content values.
Webkit browsers no longer require a -webkit- prefix for user-select: none.
The -webkit- prefix is no longer required for the filter property.
The text-decoration property no longer requires browser prefixes.

Fixes #65452.

#3 @desrosj
5 weeks ago

In 62525:

Build/Test Tools: Ensure all built files are deleted as expected.

Block editor-related files can currently become stale or are not always deleted from src through the relevant grunt clean commands reliably. In the past, this primarily caused issues locally when a CSS file was copied from the @wordpress/block-library npm package into src and later removed from the package entirely. The result was a failing grunt verify:old-files task until the grunt clean command was run with the --dev flag.

After [61438] this issue presented in new ways. Mainly, files would remain in the core.svn.wordpress.org build repository indefinitely unless explicitly deleted. [62051] brought the grunt clean tasks up to date, but there are still paths where files remain unexpectedly or have outdated contents after rebuilding. This can cause incomplete or inaccurate commits where built files subject to version control are not updated correctly, especially when changing the gutenberg.sha value in package.json.

This change improves the build script to ensure that all files sourced from the zip file with assets built by the Gutenberg repository are always fresh and up to date, and any files that are deleted from the built zip file are also deleted from version control appropriately (in both the develop and core repositories).

A handful of changes were required to accomplish this:

All Gutenberg-sourced outputs are written to src/ regardless of --dev. In production builds, build:gutenberg runs before build:files, and copy:files propagates the tree to build/.
gutenbergFiles has been split into two different arrays: gutenbergUnversionedFiles and gutenbergVersionedFiles. The src argument for the clean:gutenberg task is dynamically populated at run time with a bare grunt clean cleaning only the unversioned subset (so version-controlled files are not unexpectedly deleted), and explicit clean:gutenberg (or any chain through build:gutenberg) cleans both, removing files deleted upstream from version control.
clean:gutenberg no longer wipes non-Gutenberg sourced files from wp-includes/js/. All file/path lists have been updated to only match files the related tasks are directly responsible for managing.
tools/gutenberg/copy.js has been added to tsconfig.json and brought under tsc --build strict-mode checking. The large copyBlockAssets() function was broken into one named function per asset type, each typed against the relevant COPY_CONFIG slice. The split is a code-clarity improvement, not a bug fix.

Props desrosj, westonruter, jorbin, adamsilverstein.
Fixes #65452.

#4 @desrosj
3 weeks ago

In 62600:

Build/Test Tools: Ensure all built files are deleted as expected.

Block editor-related files can currently become stale or are not always deleted from src through the relevant grunt clean commands reliably. In the past, this primarily caused issues locally when a CSS file was copied from the @wordpress/block-library npm package into src and later removed from the package entirely. The result was a failing grunt verify:old-files task until the grunt clean command was run with the --dev flag.

After [61438] this issue presented in new ways. Mainly, files would remain in the core.svn.wordpress.org build repository indefinitely unless explicitly deleted. [62051] brought the grunt clean tasks up to date, but there are still paths where files remain unexpectedly or have outdated contents after rebuilding. This can cause incomplete or inaccurate commits where built files subject to version control are not updated correctly, especially when changing the gutenberg.sha value in package.json.

This change improves the build script to ensure that all files sourced from the zip file with assets built by the Gutenberg repository are always fresh and up to date, and any files that are deleted from the built zip file are also deleted from version control appropriately (in both the develop and core repositories).

A handful of changes were required to accomplish this:

All Gutenberg-sourced outputs are written to src/ regardless of --dev. In production builds, build:gutenberg runs before build:files, and copy:files propagates the tree to build/.
gutenbergFiles has been split into two different arrays: gutenbergUnversionedFiles and gutenbergVersionedFiles. The src argument for the clean:gutenberg task is dynamically populated at run time with a bare grunt clean cleaning only the unversioned subset (so version-controlled files are not unexpectedly deleted), and explicit clean:gutenberg (or any chain through build:gutenberg) cleans both, removing files deleted upstream from version control.
clean:gutenberg no longer wipes non-Gutenberg sourced files from wp-includes/js/. All file/path lists have been updated to only match files the related tasks are directly responsible for managing.
tools/gutenberg/copy.js has been added to tsconfig.json and brought under tsc --build strict-mode checking. The large copyBlockAssets() function was broken into one named function per asset type, each typed against the relevant COPY_CONFIG slice. The split is a code-clarity improvement, not a bug fix.

Reviewed by jorbin.
Merges [62525] to the 7.0 branch.

Props desrosj, westonruter, jorbin, adamsilverstein.
Fixes #65452.

#5 @jorbin
3 weeks ago

In 62604:

Build/Test: Fix typescript error in Gutenberg Copy.

Backporting [62600] leads to the following error: Parameter 'dep' implicitly has an 'any' type. so this gives an explicit type and also does explicit type checking.

This isn't an issue in trunk due to [62428] removing this code and re-introducing client side media so this commit is only happening in the 7.0 branch.

Developed in: https://github.com/WordPress/wordpress-develop/pull/12370
Discussed in slack thread: https://wordpress.slack.com/archives/C02RQBWTW/p1782850291418919

Follow up-to [62600].

Props jorbin, joedolson.
See: #65452.

#6 @desrosj
2 weeks ago

In 62645:

Build/Test Tools: Ensure all built files are deleted as expected.

Block editor-related files can currently become stale or are not always deleted from src through the relevant grunt clean commands reliably. In the past, this primarily caused issues locally when a CSS file was copied from the @wordpress/block-library npm package into src and later removed from the package entirely. The result was a failing grunt verify:old-files task until the grunt clean command was run with the --dev flag.

After [61438] this issue presented in new ways. Mainly, files would remain in the core.svn.wordpress.org build repository indefinitely unless explicitly deleted. [62051] brought the grunt clean tasks up to date, but there are still paths where files remain unexpectedly or have outdated contents after rebuilding. This can cause incomplete or inaccurate commits where built files subject to version control are not updated correctly, especially when changing the gutenberg.sha value in package.json.

This change improves the build script to ensure that all files sourced from the zip file with assets built by the Gutenberg repository are always fresh and up to date, and any files that are deleted from the built zip file are also deleted from version control appropriately (in both the develop and core repositories).

A handful of changes were required to accomplish this:

All Gutenberg-sourced outputs are written to src/ regardless of --dev. In production builds, build:gutenberg runs before build:files, and copy:files propagates the tree to build/.
gutenbergFiles has been split into two different arrays: gutenbergUnversionedFiles and gutenbergVersionedFiles. The src argument for the clean:gutenberg task is dynamically populated at run time with a bare grunt clean cleaning only the unversioned subset (so version-controlled files are not unexpectedly deleted), and explicit clean:gutenberg (or any chain through build:gutenberg) cleans both, removing files deleted upstream from version control.
clean:gutenberg no longer wipes non-Gutenberg sourced files from wp-includes/js/. All file/path lists have been updated to only match files the related tasks are directly responsible for managing.
tools/gutenberg/copy.js has been added to tsconfig.json and brought under tsc --build strict-mode checking. The large copyBlockAssets() function was broken into one named function per asset type, each typed against the relevant COPY_CONFIG slice. The split is a code-clarity improvement, not a bug fix.

This recommits [62525] to trunk.

Props desrosj, westonruter, jorbin, adamsilverstein.
Fixes #65452.

Reported by:	desrosj	Owned by:	desrosj
Priority:	normal	Milestone:	7.1
Component:	Bundled Theme	Version:
Severity:	normal	Keywords:	has-patch
Cc:		Focuses:

Make WordPress Core

Context Navigation

#65452 closed defect (bug) (fixed)

Twenty Nineteen: PostCSS configuration file never applies `autoprefixer`

Description

Change History (6)

This ticket was mentioned in PR #12157 on WordPress/wordpress-develop by @desrosj.

6 weeks ago #1

#2 @desrosj
5 weeks ago

#3 @desrosj
5 weeks ago

#4 @desrosj
3 weeks ago

#5 @jorbin
3 weeks ago

#6 @desrosj
2 weeks ago

Download in other formats:

Make WordPress Core

Context Navigation

#65452 closed defect (bug) (fixed)

Twenty Nineteen: PostCSS configuration file never applies `autoprefixer`

Description

Change History (6)

This ticket was mentioned in ​PR #12157 on ​WordPress/wordpress-develop by ​@desrosj. 6 weeks ago #1

#2 @desrosj 5 weeks ago

#3 @desrosj 5 weeks ago

#4 @desrosj 3 weeks ago

#5 @jorbin 3 weeks ago

#6 @desrosj 2 weeks ago

Download in other formats:

This ticket was mentioned in PR #12157 on WordPress/wordpress-develop by @desrosj.

6 weeks ago #1

#2 @desrosj
5 weeks ago

#3 @desrosj
5 weeks ago

#4 @desrosj
3 weeks ago

#5 @jorbin
3 weeks ago

#6 @desrosj
2 weeks ago