#56616 closed defect (bug) (fixed)
Running `build` scripts on Windows does not generate CSS files for blocks
Reported by: | Clorith | Owned by: | gziolo |
---|---|---|---|
Milestone: | 6.1 | Priority: | normal |
Severity: | normal | Version: | 6.0 |
Component: | Build/Test Tools | Keywords: | has-patch |
Focuses: | Cc: |
Description
Starting with WordPress 6.0, when running npm run build
or npm run build:dev
, no CSS files are generated for the blocks within wp-includes/blocks/**
.
This was discovered while investigating #56615, it is currently unknown if they are related, this ticket is for reference and tracking.
Change History (10)
#1
@
2 years ago
- Summary changed from Running `build` scripts on Windows does not generate CSS files to Running `build` scripts on Windows does not generate CSS files for blocks
This ticket was mentioned in PR #3312 on WordPress/wordpress-develop by t-hamano.
2 years ago
#3
- Keywords has-patch added
Trac ticket: https://core.trac.wordpress.org/ticket/56616
This patch unifies the forward slash as the delimiter character in the build process.
For Windows builds, path.join generates a backslashes. Thus, for example, the following process generates strange regular expressions:
{{{javascript
[
{
from: 'D:
Desktop
wp_dev
WordPress
wordpress
repo
node_modules
@wordpress
a11y
build-style
*.css',
to: 'D:
Desktop
wp_dev
WordPress
wordpress
repo
build
wp-includes
css
dist
a11y
[name].min.css',
transform: [Function (anonymous)],
noErrorOnMissing: true
},
{
from: 'D:
Desktop
wp_dev
WordPress
wordpress
repo
node_modules
@wordpress
annotations
build-style
*.css',
to: 'D:
Desktop
wp_dev
WordPress
wordpress
repo
build
wp-includes
css
dist
annotations
[name].min.css',
transform: [Function (anonymous)],
noErrorOnMissing: true
},
...
]
}}}
Furthermore, the webpack documentation recommends the use of forward slashes for from
and to
.
Don't use directly
in from option if it is a glob (i.e path\to\file.ext) option because on UNIX the backslash is a valid character inside a path component, i.e., it's not a separator. On Windows, the forward slash and the backward slash are both separators. Instead please use /.
In addition to paths containing regular expressions, I normalized all path.joins to forward slashes (to prevent problems caused by mixed path delimiters in the future).
In this patch, please check the following:
✅ On Mac/Unix, build results should match before and after applying the patch (In other words, no impact.).
✅ The build results after applying the patch should be the same on Mac/Unix and Windows.
_Note:_ As noted in the comments on Trac, some build files are CRLF on Windows and LF on Mac/Unix. It might be useful to add a new line at end of the file at build time.
2 years ago
#4
As discussed with @Clorith, it would be cool if we could add some test coverage so CI will detect if these files are present in the build or not. (We can do that in a follow-up PR though.)
2 years ago
#5
it would be cool if we could add some test coverage so CI will detect if these files are present in the build or not.
I'm new to Windows core CI, so a follow up PR would be nice 😅
2 years ago
#6
@t-hamano, can you rebase this PR to check whether all CI jobs pass now? I landed https://github.com/WordPress/wordpress-develop/commit/108c92d8dd17b928b79a3304a8e03de0bf0b6069, and all checks are green again.
#8
@
2 years ago
- Owner set to gziolo
- Resolution set to fixed
- Status changed from new to closed
In 54307:
2 years ago
#9
Committed with https://core.trac.wordpress.org/changeset/54307.
I took the diff between the results of the build with Windows OS and WSL (Ubuntu).
The following results occurred on Windows OS, including the issue of no CSS for blocks being generated.
All CSS Files aren't created
dist Directory isn't created
These files have CRLFs
I think these files are set to CRLF when the git is cloned because they don't have end with a newline code.