bigbite / build-tools Goto Github PK

Having a command that allows for incrementing the version of a specific plugin would help with how we define and perform semver increments.

Example Command Usage

Patch

build-tools version patch
# 1.2.2 → 1.2.3

Minor

build-tools version minor
# 1.2.3 → 1.3.0

Major

build-tools version major
# 1.3.0 → 2.0.0

Beta

build-tools version major:beta
# 2.0.0 → 3.0.0-beta.1

build-tools version beta
# 3.0.0-beta.1 → 3.0.0-beta.2

Increment Multiple

build-tools version minor my-plugin,my-theme
# my-plugin: 2.0.0 → 2.1.0
# my-theme: 3.4.0 → 3.5.0

We should include an example structure within the package that we can also use for integration testing on deployment. This will help with testing to make sure we're not introducing breaking changes to the package and also allow for a living example.

What happened?

SVG's can have viewBox stripped out of them which will cause the appearance of cropping when the SVGs are displayed.

@g-elwell has come across this issue which contains solutions disabling the behaviour of stripping out viewBox from SVGs. We should follow the recommendations in that reported issue to get this resolved in our build tools.

Which environments are you experiencing the issue on?

CLI (macOS, Windows, etc)

Relevant log output

No response

When including a plugin or theme from a release that has build assets and the src directory still intact, the build tools will still attempt to compile and add those entrypoints to its process and list of projects to be compiled. These types of projects are not something we should be targeting for build when running through a compile process and need to be excluded unless explicitly stated.

Originally flagged as an issue here: https://github.com/bigbite/block-footnotes/issues/36

What happened?

@g-elwell had mentioned on #33 during testing of that PR about conversion of SVGs going from to a string and then back to a component. We should investigate this and look into impacts and changes that are required. Gareth has gave reference to this as config we're likely to require.

Which environments are you experiencing the issue on?

CI (CircleCI, Travis, etc), CLI (macOS, Windows, etc)

Relevant log output

No response

What happened?

I've been refactoring an existing plugin, block-accordion, to use TypeScript. When I've pushed a commit and the CI is triggered, the build fails with an error that the @typescript-eslint plugin has failed to load on the npm run build:prod step.

Running npm run build:prod on my local CLI doesn't reproduce the same error and the build passes successfully.

Build Tools version experienced on: 1.3.0-beta.3 & 1.3.0-beta.4
Link to failed build: https://app.circleci.com/pipelines/github/bigbite/block-accordion/240/workflows/d332cbca-7b4d-4563-be44-f18420dc7a9d/jobs/145

Which environments are you experiencing the issue on?

CI (CircleCI, Travis, etc)

Relevant log output

> @bigbite/[email protected] build:prod /root/project
> build-tools build --once --production

Compiling single project in production mode.
Processing the following projects:
 * block-accordion [project/package.json]

- Building webpack configs.

Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
- Compiling...
ts-loader: Using [email protected] and /root/project/tsconfig.json
assets by status 30.1 KiB [cached] 11 assets
Entrypoint editor = ../styles/editor-7b805cfc.css editor-73e1f82e.js 2 auxiliary assets
Entrypoint frontend = ../styles/frontend-ea682dbe.css frontend-e56ad1f2.js 2 auxiliary assets
orphan modules 47.8 KiB (javascript) 1.83 KiB (runtime) [orphan] 40 modules
runtime modules 1.29 KiB 6 modules
built modules 41.3 KiB (javascript) 4.49 KiB (css/mini-extract) [built]
  javascript modules 41.3 KiB
    modules by path ./node_modules/ 3.99 KiB
      modules by path ./node_modules/prop-types/*.js 2.29 KiB 2 modules
      ./node_modules/classnames/index.js 1.38 KiB [built] [code generated]
      ./node_modules/prop-types/lib/ReactPropTypesSecret.js 314 bytes [built] [code generated]
    modules by path ./src/ 37.3 KiB
      ./src/entrypoints/editor.js + 26 modules 33.4 KiB [not cacheable] [built] [code generated]
      ./src/entrypoints/frontend.js 96 bytes [built] [code generated]
      ./src/frontend/scripts/functionality.ts 3.84 KiB [built] [code generated]
  css modules 4.49 KiB
    css ./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[6].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[6].use[2]!./node_modules/resolve-url-loader/index.js??ruleSet[1].rules[6].use[3]!./node_modules/sass-loader/dist/cjs.js??ruleSet[1].rules[6].use[4]!./src/editor/styles/editor-styles.scss 3 KiB [built] [code generated]
    css ./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[6].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[6].use[2]!./node_modules/resolve-url-loader/index.js??ruleSet[1].rules[6].use[3]!./node_modules/sass-loader/dist/cjs.js??ruleSet[1].rules[6].use[4]!./src/frontend/styles/frontend-styles.scss 1.49 KiB [built] [code generated]

ERROR in [eslint] Failed to load plugin '@typescript-eslint' declared in 'BaseConfig': Unexpected token '||='
Referenced from: BaseConfig

webpack 5.88.2 compiled with 1 error in 7165 ms



✖ Build cancelled.
?1000l?1002l?1003l?1004lnpm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @bigbite/[email protected] build:prod: `build-tools build --once --production`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @bigbite/[email protected] build:prod script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2023-08-29T10_49_24_981Z-debug.log


Exited with code exit status 1

What happened?

Testing pnpm, it fails on the install due to this package: https://www.npmjs.com/package/fibers.

States in the docs it is obsolete and doesn't support Node 16+. I can't see where it is used within the build tools so looks safe to remove this package, whether we use pnpm or not.

Expected

No issues when installing dependencies.

Which environments are you experiencing the issue on?

CLI (macOS, Windows, etc)

Relevant log output

node_modules/.pnpm/[email protected]/node_modules/fibers: Running install script...
 ELIFECYCLE  Command failed.

What happened?

When running a build, Build Tools assumes the existence of an inc/ directory in the project root. If the directory doesn't exist, a raw error is thrown by Node.js as Build Tools attempts to write to the file inc/asset-settings.php.

Ideally, Build Tools would attempt create the directory (if it doesn't exist); alternatively, a more user-friendly error message could be thrown.

The command I am running to reproduce this is

build-tools build --production --once

My directory structure looks like the following:

project/
  - dist/
  - src/
  - package.json
  - webpack.config.js
  - yarn.lock

Which environments are you experiencing the issue on?

CLI (macOS, Windows, etc)

Relevant log output

yarn run v1.22.19
warning package.json: No license field
$ build-tools build --production --once
Compiling single project in production mode.
Processing the following projects:
 *  [sample-project/package.json]

⠼ Compiling...Error: ENOENT: no such file or directory, open '/Users/jon/Code/temp/sample-project/inc/asset-settings.php'
    at Object.openSync (node:fs:601:3)
    at Object.writeFileSync (node:fs:2249:35)
    at /Users/jon/Code/temp/sample-project/node_modules/@bigbite/build-tools/src/commands/build/plugins/custom/template-generator/index.js:28:12
    at Array.forEach (<anonymous>)
    at TemplateGenerator.createTemplates (/Users/jon/Code/temp/sample-project/node_modules/@bigbite/build-tools/src/commands/build/plugins/custom/template-generator/index.js:18:20)
    at Hook.eval [as callAsync] (eval at create (/Users/jon/Code/temp/sample-project/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:9:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/Users/jon/Code/temp/sample-project/node_modules/tapable/lib/Hook.js:18:14)
    at /Users/jon/Code/temp/sample-project/node_modules/webpack/lib/Compiler.js:882:27
    at /Users/jon/Code/temp/sample-project/node_modules/neo-async/async.js:2818:7
    at done (/Users/jon/Code/temp/sample-project/node_modules/neo-async/async.js:3522:9)
    at Hook.eval [as callAsync] (eval at create (/Users/jon/Code/temp/sample-project/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at /Users/jon/Code/temp/sample-project/node_modules/webpack/lib/Compiler.js:736:33
    at /Users/jon/Code/temp/sample-project/node_modules/graceful-fs/graceful-fs.js:143:16
    at /Users/jon/Code/temp/sample-project/node_modules/graceful-fs/graceful-fs.js:61:14
    at FSReqCallback.oncomplete (node:fs:198:23) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: '/Users/jon/Code/temp/sample-project/inc/asset-settings.php'
}
1 asset
chunk (runtime: frontend) frontend-ffc666a0.js (frontend) 208 KiB [entry] [rendered]
8 modules
webpack 5.88.2 compiled successfully in 1993 ms



✔ Build complete.
✨  Done in 3.01s.

Integration of a recursive install command that will use npm install across the entirety of the site and all compatible projects.

When files that aren't static are being added to the static directory, we should think about throwing warnings with explainers of why they are not supported to make it explicitly clear at the time of parse/build. As we don't always know what a static file could be and the list is likely massive, we should probably work on a common exclusion list such as below and consider them non-static;

• .js
• .ts
• .php

Integration of a recursive CI command that will use npm ci across the entirety of the site and all compatible projects.

With a move and shift towards bringing any packages and projects up to date again, build-tools should bring in Node 18 compatibility.

Style Lint v15 has a number of depreciations that are done in favour of using Prettier. As we're using both we should look at upgrading Style Lint and removing any of the depreciated rules that we may use.

Migration Guide: https://stylelint.io/migration-guide/to-15/

What happened?

Importing select from @wordpress/data using module imports does not appear to work correctly, resulting in undefined when used.

This is affecting both watch and build bundles, and appears to be related to how the import is handled within the build tools specifically. For example:

// Build Tools

import { select } from "@wordpress/data";

console.log(select)
// select(storeNameOrDescriptor) {
//   return _default_registry__WEBPACK_IMPORTED_MODULE_0__["default"].select(storeNameOrDescriptor);
// }

console.log(wp.data.select)
// ƒ (){return m[t].apply(null,arguments)}


// WP Scripts

import { select } from "@wordpress/data";

console.log(select)
// ƒ (){return m[t].apply(null,arguments)}

console.log(wp.data.select)
// ƒ (){return m[t].apply(null,arguments)}

The end result is that attempting to use select to pull data, eg via: select('core').getUsers({ who: 'authors' })) will return the following:

TypeError: Cannot read properties of undefined (reading 'getUsers')
    at ThemerComponent (ThemerComponent.js:28:1)
    at kt (react-dom.min.js?ver=18.2.0:10:47633)
    at js (react-dom.min.js?ver=18.2.0:10:120746)
    at kl (react-dom.min.js?ver=18.2.0:10:88654)
    at yl (react-dom.min.js?ver=18.2.0:10:88582)
    at vl (react-dom.min.js?ver=18.2.0:10:88445)
    at cl (react-dom.min.js?ver=18.2.0:10:85602)
    at zn (react-dom.min.js?ver=18.2.0:10:32470)
    at dl (react-dom.min.js?ver=18.2.0:10:86098)
    at react-dom.min.js?ver=18.2.0:10:99554

In comparison, running the same command via wp.data.select or using wp-scripts as a build tool will return data.

Which environments are you experiencing the issue on?

CLI (macOS, Windows, etc)

Relevant log output

No response

In the README Commands section the examples are missing the run command and are:

npm {observable}:{environment}

and

npm watch:dev
# OR
npm build:prod

When they should be:

npm run {observable}:{environment}

and

npm run watch:dev
# OR
npm run build:prod

Hey @ampersarnie, yeah I'm seeing these on both the 1.1.1 and the pre-release bigbite/build-tools#1.2.0-beta.4 version of the build tools, the unresolved path errors are only seen when using the ?url param though 👍

Originally posted by @chrishbite in https://github.com/bigbite/content-query/pull/44#discussion_r1142040463

I've been looking into block themes and how blocks are going to be built in WP going forward, there's some interesting developments in enqueuing assets on a per-block basis.

For example, if you register a block using block.json you can define its script/style assets there - including separate ones for editor/frontend bundles. WordPress will only load the assets if the block is present on the current page, so it's a pretty cool optimisation and has already landed in core.

Since these build tools support multiple entrypoints, it's possible to get this working, but I feel like treating a block more as a 'project' could be an overall better approach, especially since a theme or plugin might have several blocks each featuring multiple entrypoints.

This could also enable block code to live together, rather than the current requirement where JS and PHP code for the same block need to be managed in separate locations, perhaps something like this (you'd potentially have multiples of these inside a specific plugin/theme):

/my-block-project
  /src
    /entrypoints
      editor.js  // client-side block registration
      frontend.js  // (optional) front-end functionality
      shared.js // (optional) for generating shared.css and/or a shared js bundle
  /dist
    editor.js
    frontend.js
    shared.css
  asset-settings.php
  block.json
  index.php // server-side block registration

The end result should be that you just need to require the index.php file in order for your block to work, since it uses block.json to register the block, and the block.json tells it which scripts/styles to enqueue. I haven't tested this fully, since I wanted to see what you all think about whether it woulda good idea to integrate this with the build tools?

I'm guessing either another folder would need to be scanned for projects, or we'd consider adding a config so you can tell the build tools which projects it should be looking for explicitly...

Ref:
https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/

What happened?

When there are no projects found, the build process will continue without bailing or reporting that there are no expected package.json files within any projects.

Recreation

Create a simple project without a package.json and run the build process from the wp-content directory.

Expectation

When no package.json files are found, the build process should end and report that none were found.

Which environments are you experiencing the issue on?

CLI (macOS, Windows, etc)

Relevant log output

No response

The feature

Our PHPCS Config enforces a maximum Cyclomatic Complexity of 10 for all PHP code. This forces users to refactor overly-complicated methods into more readable, maintainable structures.

The initial work to refactor code such that it satisfies this rule can be, admittedly, rather burdensome; so, realistically, it might not be wise to add the ESLint rule rule into existing projects.
However, the the long-term benefits can be quite significant in some cases, so I think it might be worth considering adding this rule for new projects.
Because of the old/new dichotomy, I wouldn't ordinarily suggest that it be added as part of the core Build Tools package, but the chances of folks remembering to add it in manually to new projects would be quite low. I think that allowing folks to instead turn the rule off on a per-project basis is probably the better approach.

The readme in the root of the repo links to wiki pages, but the readme in the /docs directory appears to have been updated and links to other markdown files.

The wiki is also outdated, the markdown files contain more information than what is available on the wiki.

I believe that the root readme is surplus to requirements if one is contained in a /docs directory so can be removed if it's no longer needed. Might be worth deleting the wiki as well?

To help with provide additional flexibility for projects and configurations, a configuration file setup should be created.

Identified Areas

• Directory listing - default: array['client-mu-plugins', 'plugins', 'themes']
• Hashed production file names - default: boolean true

The feature

Currently, the install command offered by the build tools will recursively run npm install across all projects.

Similar to the build command, this isn't always preferable. For example you may have installed a plugin that was build using the build tools and is detected as a project, but has built assets already.

This has came up for me on a project that has transitioned into a multisite. Originally the build tools were running within the theme directory, but now that multiple themes might exist, it makes sense to run the build tools from the project root.

This project also contains a few plugins that the build tools sees as projects, so we're using list mode to ensure that only the themes are built. Without list support for the install command, we need to rely on navigating through directories to run npm install, and having each install command listed in the ci config.

Alternative approaches

We can hook into the preinstall npm script to run npm install on our themes, e.g:

"preinstall": "(cd themes/parent-theme && npm i) && (cd themes/child-theme && npm i)",

This works well locally and should run in CI too, but if we support 'all projects' mode during install I think we should support 'list' mode too.

In fact, it probably makes sense that the project discovery logic and checks which are currently running within the build command should be extracted and shared to run across all commands.

The feature

Say, for example, that I have three entry points in a project:

• frontend.js
• editor.js
• admin.js

If I'm working on a frontend module, I likely will not need to rebuild admin.js or editor.js when making changes, as their scopes are separate from the code I'm working on. Therefore, watching and building their respective trees is unnecessary overhead in terms of both time and system resources.
This is especially true of gutenberg-related code which, in my experience, is where the most significant proportion of time is spent on a build task. On one of my projects (that isn't currently using build-tools), removing the gutenberg entry point from the Webpack build cuts the build time down by approx 66%.

It would be great if I could pass a parameter to the watch/build task to declare only the entry point(s) I want to target when I'm working on a specific feature; e.g. --entry=frontend.

Discussed in #8

What happened?

I am receiving errors for several eslint rules which should be disabled according to the provided config, and no warning for rules which should be enabled. I haven't compiled an exhaustive list as it seems most likely that some issue with the config formatting is causing it to be ignored and/or overwritten with imported rulesets we are extending from.

This seems to have been introduced since 1.2.5. Here is the CLI output from the same code on 1.3.0 and 1.2.5 for comparison:

1.3.0

1.2.5

Which environments are you experiencing the issue on?

CLI (macOS, Windows, etc)

Relevant log output

No response

The feature

Add Eslint JSDoc to the build tools to enforce adding doc blocks similar to our phpcs linting standards where doc blocks are required.

The build tools automatically generate global variables to reference dev/prod asset files, which are stored in an asset-settings.php file, but this needs to be required somewhere in order for the variables to be available in your project.

This probably just needs a line in the docs relating to the setup process, telling users where to insert the require statement.

What happened?

I have the following commands added to my package.json:

"scripts": {
    "watch:dev": "build-tools build",
    "build:prod": "build-tools build --once --production"
  },

Both work as expected locally, but the CLI seems to be having issues locating projects in a CI environment.

• In a project that uses the build tools within wp-content in site-wide mode, once pushed to CI, the build-tools will default to single-project mode - log
• Adding the --site flag doesn't seem to have any impact on this behaviour - log
• However passing a specific project positional will work - log

Note that bbv3 is the project name in the root package.json, which is what is being picked up in the first 2 instances, bigbitev3 is the project name of the theme I'm trying to build.

On another project (a plugin), I'm using the build tools in single-project mode with the same commands as above. Again, all works fine locally but once pushed to CI the build will fail - log

Which environments are you experiencing the issue on?

CI (CircleCI, Travis, etc)

Relevant log output

> [email protected] build:prod
> build-tools build --once --production

Compiling single project in production mode.
Processing the following projects:
 * bbv3 build-tools build [projects] [production] [once] [site] [quiet]

Run a new build process.

Positionals:
  projects  Comma separated list of projects to compile.  [string] [default: ""]

Options:
      --production  Build and compile production assets.
                                                      [boolean] [default: false]
      --once        Only run the process once.        [boolean] [default: false]
      --site        Run the process from the root of a site, such as from
                    wp-content.                       [boolean] [default: false]
      --quiet       Limit the amount of noise by removing webpack output.
                                                      [boolean] [default: false]
  -h, --help        Show help                                          [boolean]
  -v, --version     Show version number                                [boolean]

TypeError: Cannot read properties of null (reading '0')
    at /home/circleci/project/node_modules/@bigbite/build-tools/src/commands/build.js:102:80
    at Array.forEach (<anonymous>)
    at Object.exports.handler (/home/circleci/project/node_modules/@bigbite/build-tools/src/commands/build.js:99:12)
    at /home/circleci/project/node_modules/yargs/build/index.cjs:1:9054
    at j (/home/circleci/project/node_modules/yargs/build/index.cjs:1:4931)
    at M.applyMiddlewareAndGetResult (/home/circleci/project/node_modules/yargs/build/index.cjs:1:9023)
    at M.runCommand (/home/circleci/project/node_modules/yargs/build/index.cjs:1:7206)
    at Jt.[runYargsParserAndExecuteCommands] (/home/circleci/project/node_modules/yargs/build/index.cjs:1:56715)
    at Jt.parse (/home/circleci/project/node_modules/yargs/build/index.cjs:1:38938)
    at Object.<anonymous> (/home/circleci/project/node_modules/@bigbite/build-tools/src/cli.js:12:7)


Exited with code exit status 1
CircleCI received exit code 1