Dynamic require of "@angular/platform-browser" is not supported about angular-cli HOT 11 CLOSED

I'm going to transfer this issue to our CLI repo, but I suspect you may end up needing to file it as an issue on NX, unless you can reproduce the problem in the CLI itself.

from angular-cli.

Here's a bare setup where bootstrapApplication is within a promise then callback: StackBlitz. Both ng serve and ng serve --configuration production don't show this issue. Again, without a reproduction this won't be actionable from our end.

from angular-cli.

Concretely, this is not an Nx issue so you can close the issue over there. That said, the esbuild conversion schematic is unlikely to be updated to account for this, as 1) it wouldn't be aware of those TS options in angularCompilerOptions (they really do not belong there!) and 2) there's plenty potential reasons why esbuild may behave differently to Webpack; the CLI will never be able to account for all of it.

from angular-cli.

Without a reproduction, it's impossible to tell where this import is coming from

from angular-cli.

Well, repro steps for Nx are:

1. nx generate convert-to-application-executor
2. nx s
3. 'success build'
4. open localhost:4200
5. 'given error'

Repro steps for manuall conversion from browser to browser-esbuild:

1. In project.json edit line:
   • "builder": "@angular-devkit/build-angular:browser",
   • into: "builder": "@angular-devkit/build-angular:browser-esbuild",
2. nx s
3. 'success build'
4. open localhost:4200
5. 'given error'

from angular-cli.

I opened the issue in Nx repo: nrwl/nx#22712

from angular-cli.

For better overview, here's GIF of repro steps. Plus screen of what main.js link in console.log refers to (if it helps with something)

from angular-cli.

Here: I've cleared the company's code and keep only the wrapper of the app. It should throw the error when you open the app.
https://github.com/pr033r/angular-issue

from angular-cli.

I think that I found the solution. Maybe due to failed migration command (at least I'm expecting that those things will be fixed/migrated/rewrited) but the issues was in tsconfig.base.ts file. When I copied it from newly created project, It started working and the error message is no longer there.

Here's the commit. Check for tsconfig.base.ts

from angular-cli.

Interesting. The tsconfig.base.ts includes TypeScript options module and target in angularCompilerOptions, which happens to somewhat work due to an implementation quirk. Those options should be included in compilerOptions.

The crucial part that breaks things here is "module": "commonjs", and because it's present in angularCompilerOptions it doesn't follow the regular config cascade: although it's defined in the root tsconfig, it overrides the derived values in inherited tsconfig files—Angular reads the configuration hierarchy in two phases: first resolving the angularCompilerOptions hierarchy, then letting TypeScript load its config file with the angularCompilerOptions on top.

The CLI doesn't really support CommonJS output anymore, which is ultimately the reason why this breaks. The CLI could perhaps detect this as a warning and ignore it in favor of es2022, just like it does when target is set to an unsupported variant.

from angular-cli.

The project has been created like almost 3 years ago by different dev. I am managing this project last 1.5 year so I am surprised that any migration didn't pop up some warn/error at least 😀.

Actually, I was also wondering If I should create a new project from sratch and move all libs from old project to the new one. But it's too much work and effort. If there'd be some script to transfer all project confs files into latest schemas/formats it'd be perfect (and devs who are managing some older created projects would be calmer - that they're using updated and latest schemas/configs etc.)

Anyway, thanks for your time and effort guys. I appreciate it 😊

from angular-cli.