Skip to content

chore: degulpify the package tasks - #10323

Open
maribethb wants to merge 9 commits into
RaspberryPiFoundation:mainfrom
maribethb:gulp-package
Open

chore: degulpify the package tasks#10323
maribethb wants to merge 9 commits into
RaspberryPiFoundation:mainfrom
maribethb:gulp-package

Conversation

@maribethb

Copy link
Copy Markdown
Contributor

The basics

The details

Resolves

Fixes #10300

Proposed Changes

  • Removes gulpfiles/package_tasks.js and replaces it with a function-by-function equivalent that uses plain node scripts instead of gulp tasks.
  • Removes gulpfiles/helper_tasks.js and replaces it with several different utility files with better-organized helper functions
  • Updates other gulpfiles that referenced those helpers to use the new functions instead
  • Noteworthy changes:
    • Still uses gulp to run the build which is a prerequisite to packing, since the build is still a gulp task. At some point after build is no longer a gulp task, we should instead use the nx task graph to make sure that build is always run before packaging instead of relying on invoking it here, that way we get cacheing
    • Removed one line that was calling .replace on the contents of all the msg files to "remove references to goog.module and goog.provide" -- there weren't any of those references present, and that is a bug waiting to happen if a translation ever contains the string goog
    • we were using a gulp plugin called gulp-umd to do the umd wrapping, that's been replaced with a handwritten script that I think is not too difficult to maintain and hopefully in v14 we can stop doing umd altogether..
    • uses promise.all to do some stuff in parallel that gulp was previously doing in parallel, using a guard to make sure we're not opening too many files at once

The biggest addition in this PR is scripts/package.mjs and if you review that side-by-side with the old (deleted in this PR) gulpfiles/package_tasks.js it's easier to understand since it really is function-by-function equivalent (with the exception above about the msg files)

Reason for Changes

This is faster and easier to read

Test Coverage

Verified that the results of dist/ are identical before and after this change.

Documentation

n/a

Additional Information

This change was created with assistance from Claude and manually verified / tested / rewritten where needed

@maribethb
maribethb requested a review from a team as a code owner August 26, 2026 21:35
@maribethb
maribethb requested a review from gonfunko August 26, 2026 21:35
@maribethb maribethb changed the title Gulp package chore: degulpify the package tasks Aug 26, 2026
@github-actions github-actions Bot added the PR: chore General chores (dependencies, typos, etc) label Aug 26, 2026
@maribethb

Copy link
Copy Markdown
Contributor Author

traced the failures to a goof that happened when i deleted the package-lock to deal with the npm bug. fixed in #10378

will rebase when that's merged and fix the package-lock again but correctly this time

Comment thread packages/blockly/scripts/package.mjs Outdated
*/
async function typings(buildFlags) {
await clean();
await runGulpTask('tsc', buildFlags);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The tsc gulp task looks to be two shell commands and takes no flags. Probably just inline it here and drop the buildFlags arg from this method?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

AFAICT, this method is used only to invoke the tsc, cleanBuildDir, and build Gulp tasks. The first two are effectively one-liner shell commands, and the latter could be npm run build – maybe just do that and remove this file entirely?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This file feels like too much faffing about for one little rm – can it be inlined or consolidated into another file?

Comment on lines +17 to +19
* The file is re-read on every call so that callers always see
* up-to-date data, even if it has been modified (e.g. to bump the
* version number) since the script started.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd just drop this, this is the behavior I'd expect by default.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Removed it, but expecting it by default caused problems for us previously and we had to do the weird cache-busting workaround because subsequent reads would read the cached value. But since this is a totally different way of reading the file, it's probably fine, it's just a footgun that we've hit before.

Comment on lines +20 to +32
/**
* A dependency to be injected into a UMD module.
*
* @typedef {object} UmdDependency
* @property {string} name Name of the dependency, used as the default
* for any of the other properties that are omitted.
* @property {string=} amd Module ID to require in an AMD loader.
* @property {string=} cjs Module ID to require in a CJS loader.
* @property {string=} global Property of the global object (minus the
* leading "root.") to use in a browser.
* @property {string=} param Name of the factory function parameter the
* dependency is passed as.
*/

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Are these files actually typechecked, and if so can they just be Typescript?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

not by the runtime environment, we'd have to compile the scripts before running them which seems like it would add needless complexity and time to the build. but most IDEs can handle reading the type declarations in comments so they're still useful when writing as your IDE can yell at you even if the running script won't

Comment on lines +35 to +40
* Wrap the given script in a Universal Module Definition, so that it
* can be loaded by an AMD loader, by a CJS loader, or directly in a
* browser.
*
* This is a replacement for the gulp-umd plugin, supporting just the
* subset of its template syntax and options that our templates use.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

"Wrap the given script in a Universal Module Definition." seems adequate here? The bit about it being a replacement I'd definitely drop.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I think it's useful to know this was yanked directly out of the gulp-umd plugin so that it can be updated or we can look there if we find a bug with this or whatever.

}

/**
* Write a text file, creating its parent directories if needed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This doesn't seem to be limited to text files?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

writeFile will assume it's utf8 encoding since we didn't specify otherwise, so I think it is. i.e. this would not work to write a binary file

* (and so binary-safe) if it is omitted.
* @returns {Promise<void>} Promise resolved when copying is complete.
*/
export async function copyFiles({from, patterns, to, ignore = [], transform}) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can these just be regular args vs an options object?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

it could, but I think the call sites are a lot more readable with the names since there's so many params. any particular reason you prefer regular args?

@maribethb maribethb left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Changed a few things:

  • moved cleanReleaseDir into fs_utils
  • created cleanBuildDir there too instead of using the gulp task for it, and then replaced the gulp task in build_tasks with this script version as well
  • used npm run build and npm run tsc instead of calling the underlying gulp build task directly
  • those two things let me remove the run gulp task script
  • added a run npm task script instead, the reason for that instead of just using spawnAsync directly is that windows can't spawn npm commands unless you set shell: true so this function handles that for you
  • dropped the build args from the typings command and updated the documentation to more clearly state they only apply to pack

}

/**
* Write a text file, creating its parent directories if needed.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

writeFile will assume it's utf8 encoding since we didn't specify otherwise, so I think it is. i.e. this would not work to write a binary file

* (and so binary-safe) if it is omitted.
* @returns {Promise<void>} Promise resolved when copying is complete.
*/
export async function copyFiles({from, patterns, to, ignore = [], transform}) {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

it could, but I think the call sites are a lot more readable with the names since there's so many params. any particular reason you prefer regular args?

Comment on lines +17 to +19
* The file is re-read on every call so that callers always see
* up-to-date data, even if it has been modified (e.g. to bump the
* version number) since the script started.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Removed it, but expecting it by default caused problems for us previously and we had to do the weird cache-busting workaround because subsequent reads would read the cached value. But since this is a totally different way of reading the file, it's probably fine, it's just a footgun that we've hit before.

Comment on lines +20 to +32
/**
* A dependency to be injected into a UMD module.
*
* @typedef {object} UmdDependency
* @property {string} name Name of the dependency, used as the default
* for any of the other properties that are omitted.
* @property {string=} amd Module ID to require in an AMD loader.
* @property {string=} cjs Module ID to require in a CJS loader.
* @property {string=} global Property of the global object (minus the
* leading "root.") to use in a browser.
* @property {string=} param Name of the factory function parameter the
* dependency is passed as.
*/

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

not by the runtime environment, we'd have to compile the scripts before running them which seems like it would add needless complexity and time to the build. but most IDEs can handle reading the type declarations in comments so they're still useful when writing as your IDE can yell at you even if the running script won't

Comment on lines +35 to +40
* Wrap the given script in a Universal Module Definition, so that it
* can be loaded by an AMD loader, by a CJS loader, or directly in a
* browser.
*
* This is a replacement for the gulp-umd plugin, supporting just the
* subset of its template syntax and options that our templates use.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I think it's useful to know this was yanked directly out of the gulp-umd plugin so that it can be updated or we can look there if we find a bug with this or whatever.

@maribethb

Copy link
Copy Markdown
Contributor Author

Actually, now we don't need the npm run typings script at all since we switched to TypeDoc in the meantime and it doesn't use the generated dts files. So that simplified some things

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PR: chore General chores (dependencies, typos, etc)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

stop using gulp just to copy files

2 participants