start.node: node.js imports node:http before start.instrument runs, so HTTP instrumentation misses the server
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 1-2 天
- 新手友好度
- 30/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- node.js, typescript, vite
调研方向
The problem is the static import order in the emitted dist/server/node.js, where node:http loads before start.instrument runs inside ./server.js. Start in the plugin code that generates the node entry and check how it orders the node:* imports relative to the instrument and handler imports. Done means that with instrument set, the instrument module runs before node:http is loaded, and a build with the option shows that order.
由索引模型根据 Issue 内容生成。
描述
@solidjs/vite-plugin 3.0.0-next.50, solid-js 2.0.0-rc.15, Node 26.
With start: { node: true, instrument: './src/instrumentation.ts' }, the emitted dist/server/node.js starts with static imports:
import { createServer } from 'node:http';
// …node:fs, node:path, node:stream/promises…
import { handleRequest } from './server.js';
./server.js is where the start.instrument wrapper runs (await import(instrument); await import(handler)). Static imports are evaluated first, so node:http is already loaded when the instrument module runs. OpenTelemetry's HTTP instrumentation (@opentelemetry/auto-instrumentations-node / instrumentation-http) then misses the server: there is no HTTP server span for any request. The same instrument module works when it is passed as node --import ./dist/instrumentation.js.
The option's docs say the module "runs to completion before anything else in the server graph loads" on every surface. For start.node the entry itself breaks that.
What we see: we run an instrument module that starts the OpenTelemetry NodeSDK, and serve through the node entry (createListener from dist/server/node.js). Run that way, the collector gets no HTTP SERVER span for any request. With the same module passed as node --import, every request gets one. The import order above is the reason as far as we can tell. We have not reduced it to a standalone repo.
Suggestion: when instrument is set, have the node entry await it before the node:* imports. One way is to emit await import(instrument) at the top of node.js and load the rest of the entry through a dynamic import. Another is to load node:http lazily inside serve / createListener.
We pass --import for now, so the option is unused in our apps.
- 主要语言
- TypeScript
- 星标
- 522
- 派生
- 73
- 平均合并
- 1 天 5 小时
- 30 天内合并 PR
- 34
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
solidjs/solid-vite-plugin 的其他 Issue
-
Test environment detection doesn't consider Vitest workspaces可能已有人在做 @carloitaben 于 54 天前认领。 未关闭1.x
难度 2/5 1-3 小时 新手友好度 78/100
solidjs/solid-vite-plugin#205 · 1 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
-
难度 3/5 半天 新手友好度 55/100
solidjs/solid-vite-plugin#420 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
solidjs/solid-vite-plugin#419 ·
维护者通常 1 天内回复
-
Dev manifest bridge keeps stale CSS after an edit可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 34/100
solidjs/solid-vite-plugin#415 ·
维护者通常 1 天内回复
-
Dev manifest loses lazy CSS when imported before HTTP startup可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 25/100
solidjs/solid-vite-plugin#414 · 1 条评论 ·
维护者通常 1 天内回复
查看 solidjs/solid-vite-plugin 的全部 Issue
相似的 Issue
-
area:ui effort:S enhancement priority:P2
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
QuantumNous/new-api#7839 ·
维护者通常 1 天内回复
-
good first issue maintenance
难度 2/5 1-3 小时 新手友好度 62/100
dark-princezz/stellar-hooks#1010 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
interledger/rhyza#352 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复