GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — fix(vite): scan top-level imports with Vite's native parser by aleclarson · Pull Request #11634 · NativeScript/NativeScript

Conversation

@aleclarson

@aleclarson aleclarson commented Nov 10, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

What

The /ns/m dev route parses each served module with Babel several times just to find its top-level imports (collectTopLevelImportRecords in two places, plus the dev default-import link check). On modules whose code sits on a few very long lines, Babel's skipBlockComment becomes quadratic: for every block comment it runs lineBreakG.test(this.input) from the comment start to the next line break anywhere in the input, not just to the comment's end.

Real case: a 3.9 MB dependency chunk (shaders/dist/core/std-*.js) is transformed by Vite's dev pipeline into 225 lines, the longest 1.9 MB with about 2,000 block comments. One Babel parse of that output takes ~1.5 s (0.26 s on the original multi-line file), and a single cold request did about six of them. CPU profiles showed @babel/parser at 8.7 s of an 11.25 s request, 7.2 s of it in skipBlockComment. Because this runs synchronously, the dev server's event loop is blocked for the whole request, and the iOS runtime's module loader timed out during cold boot (NSURLErrorDomain -1001) before the app could start.

How

  • New parseTopLevelStatements(code) in websocket-served-module-helpers.ts returns top-level statements from Vite's parseAst(code, { lang: 'tsx' }) (Oxc), or null if Oxc rejects the code.
  • Both collectTopLevelImportRecords implementations use it first and fall back to the unchanged Babel parse. If both fail, they still return []. Node checks are plain type comparisons that work on either AST. Output fields are unchanged.
  • New collectStaticImportDefaultIntents(code) replaces the link check's inline parse and traverse. Static imports can only appear at top level, so scanning top-level ImportDeclarations is equivalent. It falls back to the previous Babel parse and traverse, and still throws on a double failure, so the caller's try/catch behaves as before.
  • Other Babel uses (astExtractImportsAndStripTypes, collectReExportAndDynamicImportSources, the normalizer) are untouched.

vite is already a dependency of @nativescript/vite (^8.0.0), so no new dependency.

Test plan

  • npx vitest run hmr/server/websocket-served-module-helpers.spec.ts hmr/server/websocket-import-records-fallback.spec.ts: 26 pass. Covers default, named and string-named specifiers, exact text slices after non-ASCII text, import type, TS+JSX input, no imports, a forced Oxc failure falling back to Babel, ensureNativeScriptModuleBindings on both paths, and default-import intents.
  • Long-line regression: one import plus a single line with 12,000 block comments. Babel-only took 10.3 s on this machine; the new path takes about 0.05 s. The spec asserts under 2 s.
  • npx nx run vite:build. Touched files are lint-clean; vite:lint still reports 3 existing errors in untouched files (configuration/base.ts, css-device-module.ts).
  • Applied as a patch to published 8.0.20 and 8.0.21 in a large app. A cold request for the module above went from 11–21 s to 5–9 s on a heavily loaded host (load average 40–190); the rest is untouched Babel work and the Vite transform. The @babel/parser share dropped from 8.7 s to 1.2 s. A serial cold crawl of the app's 1,443-module boot graph went from 241.6 s to 108.9 s, with the slowest module dropping from 4.9 s to 1.4 s.
  • The same app now completes an iOS simulator HMR cycle from a cold dev server: launch, an in-place JS edit on the same process, and a native edit with rebuild and relaunch. Before this change it failed during module loading.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@aleclarson
fix(vite): scan top-level imports with Vite's native parser
f9a2a09
Babel's skipBlockComment rescans to the next line break for every block comment, so a module whose code sits on a few very long lines parses quadratically. A large served dependency (about 2,000 block comments on a 1.9 MB line) took ~1.5 s per Babel parse, and the /ns/m pipeline parsed it about six times per request while blocking the dev server event loop. iOS loader requests then timed out during cold boot.

Top-level import record collection and the dev default-import link check now use Vite's parseAst (Oxc) and fall back to the previous Babel parse when Oxc rejects the input.
@nx-cloud

nx-cloud Bot commented Nov 10, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown

View your CI Pipeline Execution ↗ for commit f9a2a09

Command Status Duration Result
nx test apps-automated -c=android ✅ Succeeded 3m 32s View ↗
nx run-many --target=test --configuration=ci --... ✅ Succeeded <1s View ↗

💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗


☁️ Nx Cloud last updated this comment at 2026-11-10 20:32:42 UTC

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@pkg-pr-new

pkg-pr-new Bot commented Nov 10, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@nativescript/core@11634
npm i https://pkg.pr.new/@nativescript/vite@11634
npm i https://pkg.pr.new/@nativescript/webpack@11634

commit: f9a2a09

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

1 participant

@aleclarson
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.