1.2.4

What's Changed

• Fix and correct nvm and npm rc files by @ampersarnie in #94
• Disable PHPCS for auto-generated asset settings file by @jonmcp in #93

New Contributors

• @jonmcp made their first contribution in #93

Full Changelog: 1.2.3...1.2.4

1.3.0 β2

Whats New?

TypeScript

1.3 introduces support for TypeScript within Build Tools with the aims of creating an easy to use implementation that requires as little configuration as possible to keep a consistent approach to projects that are written in TypeScript and are compiled using Build Tools.

TypeScript Default Config and Rules

The aim for bundling the config was to provide a sane setup for each developer that is working within TypeScript that will also provide consistency across all projects that utilise it.

The configuration for TypeScript can be found in the configs/tsconfig.json file.

There are also some image definition types that can be found in the configs/tsconfig/images.d.ts file.

An addition of TypeScript ESLint has also been included to ensure that we've support for ESLint within our builds.

Project tsconfig.json

As part of the aim is to provide a bundled configuration file, the tsconfig.json is defined within the project and can be found amongs other related configuration files within the /configs directory. The config file aims to provide a sane standard as recommended in the issue comment here.

To ensure the config file is visible by IDEs and any other related software for error and syntax highlighting, you need to define and extend the tsconfig.json within the root of your project.

{
  "extends": "@bigbite/build-tools/configs/tsconfig"
}

Customising tsconfig.json

There are a number of situations where you may need to customise or extend the tsconfig.json. This can be easily achieved by utilising the extends property and pointing to the build-tools config to use as the base.

{
  "extends": "@bigbite/build-tools/configs/tsconfig",
  "include": [
    "src/entrypoints",
    "src/types"
  ],
}

Please note that extending has additional effects when implementing include and exclude. Read the documentation for extends here.

Alternatively, if you need an entirely different tsconfig.json than the one that is provided, a tsconfig.json that is placed in the root of the project will be picket up by the build-tools, whether it is extended or not.

Performance Improvements

An improvement to project discovery has been added to speed up seeking of compatible projects. There should be no breaking changes or alterations for existing usages and implementations of build-tools.

What's Changed

• chore(deps): bump webpack from 5.72.1 to 5.76.0 by @dependabot in #75
• Add unit and integration tests by @g-elwell in #67
• Add unit test run in ci by @ampersarnie in #81
• Base project discovery around package.json first by @g-elwell in #70
• TypeScript Support by @ampersarnie in #90

Full Changelog: 1.2.3...1.3.0-beta.2

1.2.3

What's Changed

• Add checks for which externals are set when running Dependency Extraction by @ampersarnie in #87

Full Changelog: 1.2.2...1.2.3

1.2.2

Updated version tag after 1.2.1 failed to publish to npm

1.2.1

What's Changed

• Add unit and integration tests by @g-elwell in #67
• Add unit test run in ci by @ampersarnie in #81
• Disable react/prop-types in eslint config by @ampersarnie in #84
• Fix issues where depencies would not extract correctly. by @ampersarnie in #83

Full Changelog: 1.2.0...1.2.1

1.3.0 β1

Whats New?

Performance Improvement

An improvement to project discovery has been added to speed up seeking of compatible projects. There should be no breaking changes or alterations for existing usages and implementations of build-tools.

What's Changed

• chore(deps): bump webpack from 5.72.1 to 5.76.0 by @dependabot in #75
• Add unit and integration tests by @g-elwell in #67
• Add unit test run in ci by @ampersarnie in #81
• Base project discovery around package.json first by @g-elwell in #70

Full Changelog: 1.2.0...1.3.0-beta.1

1.2.0

Whats New?

WordPress Dependency Extraction

Support for usage of @wordpress packages within code to allow for more native and standard usage of Gutenberg elements.

// Previously
const { registerBlockType } = wp.block;
const { __ } = wp.i18n;

// Now supported:
import { registerBlockType } from '@wordpress/blocks';
import { __ } from '@wordpress/i18n';

Accessing Dependency Array

As outlined in the Working with your Assets page on the wiki, asset information is placed in global PHP constants from the inc/asset-settings.php file. If we have an entry point of editor.js in a plugin/project called test-plugin that takes advantage of @wordpress packages, a new constant will be defined.

Constants with the suffix of _DEPENDENCIES will contant the array required.

define( 'TEST_PLUGIN_EDITOR_CSS', 'editor.css' );
define( 'TEST_PLUGIN_EDITOR_JS', 'editor.js' );

define( 'TEST_PLUGIN_EDITOR_DEPENDENCIES', ["react","wp-blocks","wp-i18n"] );
define( 'TEST_PLUGIN_VERSION', 'v0.0.0' );

Any entrypoints and subsequent scripts without dependencies will contain an empty array.

Aliases

To aide with directory traversion within components or files we can add a number of predefined aliases that allow for easier time with referencing directories based around a common structure that we use for our projects. This means we can avoid backstepping through directories to get back to a base directory. For example we may find we have a situation where we're backstepping to get to the components directory like this;

const { MyButtons } from '../../../components/buttons';

With aliases, this can easily be replaced with the following if required;

const { MyButtons } from '@Components/buttons';

The following are currently supported;

• @Components → {project-root}/src/components
• Components → {project-root}/src/components
• @Static → {project-root}/src/static
• Static → {project-root}/src/static
• @Utils → {project-root}/src/utils
• Utils → {project-root}/src/utils

Static File Checking

To ensure that file with extensions such as js and php are being flagged as in the incorrect location, a file check has been added with a warning. This has been implemented using a custom plugin to handled checks against files as webpack parses through them. Warnings will be shown in a similar manner to other parsing or linting warnings in the post compile report within the CLI.

Linting Changes

• Disables the react/require-default-props rule as this is now depreciated.

Change Log

• Adds alias resolving support to projects.
• Adds support for @wordpress packages using DependencyExtraction as a custom extension of @wordpress/dependency-extraction-webpack-plugin package. See #60.
• Removes HTMLWebpack plugin.
• Adds custom TemplateGenerator plugin.
• Refactors assetSettings template function.
• Adds custom AssetMessage plugin.
• Adds rules for AssetMessage.

1.1.2

Change Log

• Removes fibers package.

Full Changelog: 1.1.1...1.1.2

1.2.0 β4

⚠️ This is a Beta release. Do not use in production.

Whats New?

WordPress Dependency Extraction

Support for usage of @wordpress packages within code to allow for more native and standard usage of Gutenberg elements.

// Previously
const { registerBlockType } = wp.block;
const { __ } = wp.i18n;

// Now supported:
import { registerBlockType } from '@wordpress/blocks';
import { __ } from '@wordpress/i18n';

Accessing Dependency Array

As outlined in the Working with your Assets page on the wiki, asset information is placed in global PHP constants from the inc/asset-settings.php file. If we have an entry point of editor.js in a plugin/project called test-plugin that takes advantage of @wordpress packages, a new constant will be defined.

Constants with the suffix of _DEPENDENCIES will contant the array required.

define( 'TEST_PLUGIN_EDITOR_CSS', 'editor.css' );
define( 'TEST_PLUGIN_EDITOR_JS', 'editor.js' );

define( 'TEST_PLUGIN_EDITOR_DEPENDENCIES', ["react","wp-blocks","wp-i18n"] );
define( 'TEST_PLUGIN_VERSION', 'v0.0.0' );

Any entrypoints and subsequent scripts without dependencies will contain an empty array.

Aliases

To aide with directory traversion within components or files we can add a number of predefined aliases that allow for easier time with referencing directories based around a common structure that we use for our projects. This means we can avoid backstepping through directories to get back to a base directory. For example we may find we have a situation where we're backstepping to get to the components directory like this;

const { MyButtons } from '../../../components/buttons';

With aliases, this can easily be replaced with the following if required;

const { MyButtons } from '@Components/buttons';

The following are currently supported;

• @Components → {project-root}/src/components
• Components → {project-root}/src/components
• @Static → {project-root}/src/static
• Static → {project-root}/src/static
• @Utils → {project-root}/src/utils
• Utils → {project-root}/src/utils

Linting Changes

• Disables the react/require-default-props rule as this is now depreciated.

Change Log

• Adds alias resolving support to projects.
• Adds support for @wordpress packages using DependencyExtraction as a custom extension of @wordpress/dependency-extraction-webpack-plugin package. See #60.
• Removes HTMLWebpack plugin.
• Adds custom TemplateGenerator plugin.
• Refactors assetSettings template function.

1.1.1

What's Changed

• fix: add error check to bail in production mode by @g-elwell in #63

Full Changelog: 1.1.0...1.1.1