Repository navigation
Conversation
@jsmodule is for build-time bundle sources only. A @jsmodule value with a runtime URL prefix (context://, base://, /abs, http(s)://, //) keeps working at runtime via Page.addJsModule, but is now filtered out of the bundle imports and triggers a build-time deprecation warning. - The scanner (FrontendClassVisitor) tracks such values on ClassInfo.deprecatedRuntimeModules instead of adding them to the bundle imports. - FrontendDependencies emits a one-time consolidated build-time warning per (class, value) recommending migration to @javascript(value=..., type=Type.MODULE) for runtime <script type="module"> loading. This removes the previous double-load where an external @jsmodule URL was both bundled and loaded at runtime.
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… checks Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Fixed the three SonarCloud issues: the two lambdas in |
# Conflicts: # flow-build-tools/src/test/java/com/vaadin/flow/server/frontend/scanner/FrontendDependenciesTest.java
|
If this depends on another PR, let's stack it on top of that/those |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…dule-is-bundle # Conflicts: # flow-build-tools/src/main/java/com/vaadin/flow/server/frontend/scanner/FrontendDependencies.java # flow-build-tools/src/test/java/com/vaadin/flow/server/frontend/scanner/FrontendDependenciesTest.java # flow-build-tools/src/test/java/com/vaadin/flow/server/frontend/scanner/samples/RuntimeJavaScriptComponent.java # flow-server/src/test/java/com/vaadin/flow/component/internal/RuntimeJavaScriptDependencyTest.java # flow-server/src/test/java/com/vaadin/flow/server/FrontendDependencyUrlResolverTest.java
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The full-classpath scanner, used in development mode by default, only skipped runtime-prefixed @javascript values, so a @jsmodule with a runtime URL was still bundled there while also being loaded at runtime. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…deprecation Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@Artur- Done — this PR is now stacked on #24653: the base is |
…dule-is-bundle # Conflicts: # flow-server/src/main/java/com/vaadin/flow/component/internal/UIInternals.java # flow-server/src/test/java/com/vaadin/flow/component/internal/RuntimeJavaScriptDependencyTest.java
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…dule-is-bundle # Conflicts: # flow-server/src/test/java/com/vaadin/flow/component/internal/RuntimeJavaScriptDependencyTest.java
|
Merged |
A @jsmodule value only reaches this point when it already has a runtime URL prefix, which resolveToContextRoot returns unchanged, so it can never resolve to null. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|





Stacked on #24653 — review/merge that first; this PR's base is
javascript-is-runtime.@jsmodule is for build-time bundle sources only. A @jsmodule value with a runtime URL prefix (context://, base://, /abs, http(s)://, //) keeps loading at runtime as a
<script type="module">(viaPage.addJavaScript(url, LoadMode.EAGER, JavaScript.Type.MODULE)), but is now filtered out of the bundle imports and triggers a build-time deprecation warning.<script type="module">loading.@JsModuleJavadoc documents the deprecation and points to@JavaScript(type = Type.MODULE).