René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Feature]: CSP-safe worker execution mode (remove the mandatory `'unsafe-eval'`)","articleBody":"**Pre-flight checklist**\n- [x] I searched existing issues and did not find a duplicate request.\n- [x] I explained the problem or use case, not just the desired API.\n\n**Problem or use case**\n`concurrency` currently revives worker bodies with `new Function(...)`, which forces applications to allow `'unsafe-eval'` in their Content-Security-Policy (plus `worker-src blob:`). This is a non-starter for security-conscious deployments and is self-contradictory in a framework that ships a security module and markets \"secure by default.\" It is the primary blocker to `concurrency` leaving Experimental (#133).\n\n**Proposed solution**\nProvide a default execution mode that does not require `'unsafe-eval'` — for example, dispatching to pre-registered module workers addressed by URL (static `Worker(new URL(...))`) and passing only serializable payloads, rather than serializing function bodies for eval-based revival. Keep the current dynamic mode available as an explicit opt-in for users who accept the CSP trade-off, but make the safe mode the documented default so the out-of-the-box posture is CSP-clean.\n\n**Possible API or UX shape**\n```ts\nimport { createPool, defineWorker } from \"@bquery/bquery/concurrency\";\n\n// Registered module worker — no eval, CSP-clean.\nconst heavy = defineWorker(new URL(\"./heavy.worker.ts\", import.meta.url));\n\nconst pool = createPool({ mode: \"module\" }); // \"module\" (default) | \"dynamic\" (opt-in, needs unsafe-eval)\nconst result = await pool.run(heavy, payload);\n```\n\n**Alternatives considered**\nDocumenting the CSP requirement and leaving it as-is — unacceptable for a security-first framework and an adoption blocker. Dropping dynamic function workers entirely — too disruptive for existing users; keeping them as an explicit opt-in preserves flexibility while fixing the default.\n\n**Relevant area**\n`concurrency`\n\n**Additional context**\nAlso relevant to `security`. `createSharedBuffer()`'s `crossOriginIsolated` requirement is inherent to `SharedArrayBuffer` and can stay documented as-is; this ticket is specifically about removing the *eval* requirement, which is bQuery's own implementation choice rather than a platform constraint.\n","author":{"url":"https://github.com/JosunLP","@type":"Person","name":"JosunLP"},"datePublished":"2026-06-26T21:25:15.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/134/bQuery/issues/134"}