You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing could make the whole flow you worked on more transparent: create an explicit link (dependency) between the setup-env and install-env targets.
When I look at the task pipeline, I can see clearly, e2e target will trigger setup-env:
But what will setup-env trigger? Now I know (since I navigated through the codebase) that it will call the install-env executor declared by the Nx plugin createNodes API.
This is all very implicit...
As soon as you search for install-e2e, TADA, things become clearer because targets have self-describing names:
Could we imagine a refactoring of the runSetupEnvironmentExecutor that depends on install-env running first?
Do you think this flow should remain opaque?
The text was updated successfully, but these errors were encountered:
I really like the feedback!! I was already tempted to refactor it as I see it as a big downside that is is all implicit.
I did not go on with the refactor as we had no tests so far.
Now that at least unit tests are in we can more confidently change the codebase.
One thing could make the whole flow you worked on more transparent: create an explicit link (dependency) between the
setup-env
andinstall-env
targets.When I look at the task pipeline, I can see clearly,
e2e
target will triggersetup-env
:But what will
setup-env
trigger? Now I know (since I navigated through the codebase) that it will call theinstall-env
executor declared by the Nx plugincreateNodes
API.This is all very implicit...
As soon as you search for
install-e2e
, TADA, things become clearer because targets have self-describing names:Could we imagine a refactoring of the
runSetupEnvironmentExecutor
that depends oninstall-env
running first?Do you think this flow should remain opaque?
The text was updated successfully, but these errors were encountered: