nx build doesn't use previous build steps

mhamri commented 1 year ago

Current Behavior

I'm reopening #19404 since I believe unfortunately @AgentEnder didn't spend time and closed the issue without understanding the main problem (Irony of his username)

the issue is the build results, not angular (against @AgentEnder understanding)

builds are not using previous build step result. having a rollup next to vite next to esbuild means nothing in nx mono repo. main question is

what exactly nx is caching if each of the build steps are not using the previous build result?

because if it's not for the sake of caching and build-once-use-many, using npm's workspace would be more wise.

I have created a repository that shows when the target build is a vite project or rollup project or an esbuild project. previous build step isn't used in the next build step.

to be clear that "the issue isn't about angular" I've removed the angular application from the repository!

Expected Behavior

build once, use multiple times. each build step should use previous build result. helps to decrease build effort and memory usage.

GitHub Repo

https://github.com/mhamri/Bundling-Issues-in-Nx

Steps to Reproduce

create an empty nx project
create a rollup project using @nx/js
add a plugin to rollup project to replace text during the build

in rollup project we have __IsRollup__ and

we set a plugin to replace the text

create a vite Project using @nx/js
add a plugin to vite project to replace text during the build

in vite project we use rollup()

configure the vite plugin to replace IsVite

repeat the same thing with different type of project (in repo I created esbuild too)
build vite project
visit the dist folder and see if all the text in both project is replaced or not

by here you can stop, you already saw that build is broken but if you want to test more

add a nodejs project with @nx/node
call viteToRollup()
see output

Nx Report

Enumerating objects: 112, done.
Counting objects: 100% (112/112), done.
Delta compression using up to 8 threads
Compressing objects: 100% (97/97), done.
Writing objects: 100% (112/112), 291.45 KiB | 7.88 MiB/s, done.
Total 112 (delta 22), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (22/22), done.
To https://github.com/mhamri/Bundling-Issues-in-Nx.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.
PS C:\repo\toDelete\ngrx-nx-workshop\test-lib-connection\dist\apps\is-angular> nx report
>  NX  Falling back to ts-node for local typescript execution. This may be a little slower.
  - To fix this, ensure @swc-node/register and @swc/core have been installed

 >  NX   Report complete - copy this into the issue template

   Node   : 16.20.0
   OS     : win32-x64
   npm    : 8.19.4

   nx (global)        : 16.9.1
   nx                 : 16.9.1
   @nx/js             : 16.9.1
   @nx/jest           : 16.9.1
   @nx/linter         : 16.9.1
   @nx/workspace      : 16.9.1
   @nx/angular        : 16.9.1
   @nx/esbuild        : 16.9.1
   @nx/eslint-plugin  : 16.9.1
   @nx/rollup         : 16.9.1
   @nx/vite           : 16.9.1
   typescript         : 5.1.6

Failure Logs

No response

Package Manager Version

pnpm 8.9.0

Operating System

[ ] macOS
[ ] Linux
[X] Windows
[ ] Other (Please specify)

Additional Information

No response

AgentEnder commented 1 year ago

Hey @mhamri, sorry if I was not clear before. The tutorial I linked may have been geared towards angular, but the concepts it goes over are related to what you are seeing. Most of our bundler executors default to building the library code from source, for a variety of reasons which other people would be more versed to explain.

Regardless, if you do not wish for the bundler to build the library from source, and would rather it build from dist which can make sense in some use cases, most of our executors accept an option buildLibsFromSource. This is what I was referring to as the angular tutorial covers it.

See:

It doesn't look like those options are currently supported for esbuild and rollup, if you need to consume libraries from dist and a parent project is using either of those you should open a feature request to support it. Either way, the consuming app in your repo does use vite, which supports the option, so passing it should resolve the issue you are describing.

mhamri commented 1 year ago

@AgentEnder is it possible to not close the issue until we have a clear resolution?

I've tried what you've suggested and it didn't work

1- added another vite project with @nx/js 2- added the plugin to replace the text __IsVite2__ in the second project