You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 48e10d4
Browse filesBrowse the repository at this point in the historyBrowse files
feat(cli,build,core): complete the dev createRequire warning, diagnostics-only suppression
Adds the scan/suppression halves of the dev warning (the devSession wiring
landed in the previous commit): nested-arg matching feeds both targets, and
a usage only warns when the package is missing from the resolved externals
and every configured external. additionalPackages declares its packages via
a new diagnostics-only BuildExtension field, installedPackagesForTarget, so
a configured fix silences the warning without changing bundling output.
Deploys now warn when a package is loaded with `createRequire()` but won't be available in the deployed image. The bundler can't follow `createRequire()` calls, so such a package is neither bundled nor installed, and previously this failed only at runtime with a confusing module-not-found error. The warning points at the exact file and line and suggests the `additionalPackages`build extension. Deploys also now surface the bundler's own warnings for your files (for example `require()` with a non-literal argument) instead of discarding them.
7
+
`deploy` and `dev`now warn when a package is loaded with `createRequire()` but won't be available in the deployed image. The bundler can't follow `createRequire()` calls, so such a package is neither bundled nor installed, and previously this failed only at runtime in production with a confusing module-not-found error (`dev` works because your local `node_modules` exists, which made the failure deploy-only). The warning points at the exact file and line and shows the `additionalPackages`config that fixes it; packages declared via `additionalPackages` don't warn. Deploys also now surface the bundler's own warnings for your files (for example `require()` with a non-literal argument) instead of discarding them. Bundling output is unchanged.
? `"${usage.specifier}" is loaded with createRequire(). This works locally because your project's node_modules exists, but the package won't be available in the deployed image, so deploys of this code will fail at runtime. The bundler can't follow createRequire() calls, so "${usage.packageName}" is neither bundled into your code nor installed in the image.`
273
+
: `"${usage.specifier}" is loaded with createRequire() but won't be available in the deployed image, so loading it will fail at runtime. The bundler can't follow createRequire() calls, so "${usage.packageName}" is neither bundled into your code nor installed in the image.`;
274
+
247
275
return{
248
276
pluginName: "create-require-collector",
249
-
text: `"${usage.specifier}" is loaded with createRequire() but won't be available in the deployed image, so loading it will fail at runtime. The bundler can't follow createRequire() calls, so "${usage.packageName}" is neither bundled into your code nor installed in the image.`,
277
+
text,
250
278
location: {
251
279
file: usage.file,
252
280
line: usage.line,
@@ -266,7 +294,7 @@ export function createRequireUsageToWarning(usage: CreateRequireUsage): esbuild.
266
294
},
267
295
});
268
296
269
-
Alternatively, import the package statically so it gets bundled. Docs: https://trigger.dev/docs/config/extensions/additionalPackages`,
297
+
Alternatively, replace the createRequire() call with a static import so the package is bundled. Docs: https://trigger.dev/docs/config/extensions/additionalPackages`,
0 commit comments