[FIX] Allow usage of after/before task assignment for all standard tasks #628
Conversation
flovogt
force-pushed
the
allow-task-assignment-generateBundle
branch
2 times, most recently
from
12fa0d4 to
4ecef82
Compare
When migrating an project from V2 to V3 the after/before task assignments of custom tasks often has to be adjusted because the task `uglify` got removed and new `minify` task is executed earlier as the `uglify` task. In the migration guide we have written that we can not make any assumptions about the task which should be used as the new "last" task executed by the standard UI5 Tooling build tasks. See https://sap.github.io/ui5-tooling/stable/updates/migrate-v3/#removal-of-standard-tasks-and-processors. In the above mentioned documentation we have a list with all tasks and the execution order. Currently, it works to assign a custom task after/before a task which is not executed at all. So you can assign a custom task to `afterTask: generateVersionInfo` although the task `generateVersionInfo` is not executed. This works for every standard UI5 Tooling build task except for `generateBundle`. This PR aligns the behaviour also for the `generateBundle` task. JIRA: CPOUI5FOUNDATION-724
matz3
force-pushed
the
allow-task-assignment-generateBundle
branch
from
4ecef82 to
4962e9e
Compare
There was a problem hiding this comment.
I got from the description that we currently face issues only with generateBundle, but I also can see potential issues of the same kind in the following places:
lib/build/definitions/library.jsgenerateComponentPreloadtaskgenerateBundletask (already addressed in the comments)generateThemeDesignerResourcestask
lib/build/definitions/themeLibrary.jsgenerateThemeDesignerResourcestask
I'm unsure whether we need to address those now, but they seem the same.
There was a problem hiding this comment.
I missed some detail when recommending to just use null as taskFunction.
The task logger used in runTasks must only receive the list of task which are actually executed and logged. Otherwise it will wait forever and the build never succeeds (you should be able to verify that e.g. with openui5-sample-app).
So the allTasks list must not include tasks which should not be executed. So the initial solution should be fine (using composeTaskList) as long as the logic is added after the include/excludes are handled because such a no-op task should never be enabled.
matz3
changed the title
JIRA: CPOUI5FOUNDATION-724 This PR aims to improve the documentation by providing correct information based on a related change for custom tasks subscription & execution order behaviour: SAP/ui5-project#628 --------- Co-authored-by: Günter Klatt <[email protected]>
This change allows custom tasks to subscribe to any standard task, even disabled ones, ensuring custom tasks' execution and the correct order.
Background information:
When transitioning a project from V2 to V3, we often need to adjust the before/after task assignments for custom tasks due to the removal of the
uglifytask. The newminifytask now runs earlier than the previousuglifytask.Developers typically used
uglifyas the last enabled standard task to subscribe to.You can find updated documentation here: SAP/ui5-tooling#874
JIRA: CPOUI5FOUNDATION-724