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

Try to generalize build transforms #16317

Closed
wants to merge 2 commits into from

Conversation

talldan
Copy link
Contributor

@talldan talldan commented Jun 26, 2019

Description

As mentioned in #16150 (comment), the solution for handling block.json files when npm run dev is running introduces some code duplication. This PR tries to reduce that duplication

How has this been tested?

Test that npm run build and npm run dev continue to work.

Types of changes

Refactor (non-breaking change which adds functionality)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.

@talldan talldan added [Type] Task Issues or PRs that have been broken down into an individual action to take [Type] Build Tooling Issues or PRs related to build tooling labels Jun 26, 2019
@talldan talldan self-assigned this Jun 26, 2019
const packages = new Set;
function createEntryTransform( mappingFunc ) {
// Track any already built files to avoid duplication.
const fileSet = new Set;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second commit in this branch introduces this generic way to avoid duplicate built files, but I'm not sure it's the right solution.

It doesn't avoid repeating expensive operations in the mappingFunc, which I imagine was the original intention for tracking changed packages. (cc @aduth)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, yeah, I see what you mean. Maybe we can pass fileSet as the second argument in the mapping function to allow the callback to determine whether to defer to a cached value?

Or if we really want to follow Array#map signature, as the third argument, and likely as an array and not a set (documentation).

@talldan talldan changed the title Try/generalize build transforms Try to generalize build transforms Jun 26, 2019
// Only operate once per package, assuming entries are common.
const packageName = getPackageName( file );
if ( packages.has( packageName ) ) {
if ( isString( mapped ) && ! fileSet.has( mapped ) ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we just normalize this value to an array and skip directly to the forEach below?

https://lodash.com/docs/4.17.11#castArray


// Build all root level stylesheets for the package.
const packageName = getPackageName( file );
const rootScssFiles = await glob( path.resolve( PACKAGES_DIR, packageName, 'src/*.scss' ) );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The capitalization of this as an acronym should be rootSCSSFiles.

https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/#abbreviations-and-acronyms

That said, I don't think we need a variable here, just return await ...

const packages = new Set;
function createEntryTransform( mappingFunc ) {
// Track any already built files to avoid duplication.
const fileSet = new Set;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, yeah, I see what you mean. Maybe we can pass fileSet as the second argument in the mapping function to allow the callback to determine whether to defer to a cached value?

Or if we really want to follow Array#map signature, as the third argument, and likely as an array and not a set (documentation).

@talldan
Copy link
Contributor Author

talldan commented Jan 21, 2020

Closing this for now—happy for it to be picked up by someone else, but not seeing much value on working on it more.

@talldan talldan closed this Jan 21, 2020
@aduth aduth deleted the try/generalize-build-transforms branch January 21, 2020 13:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Build Tooling Issues or PRs related to build tooling [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants