sentry-javascript: Astro could not resolve X
Is there an existing issue for this?
- I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- I have reviewed the documentation https://docs.sentry.io/
- I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
SDK Version
7.85.0
Framework Version
4.0.3
Link to Sentry event
No response
SDK Setup
import cloudflare from "@astrojs/cloudflare"
import svelte from "@astrojs/svelte"
import tailwind from "@astrojs/tailwind"
import { defineConfig } from "astro/config"
import mkcert from "vite-plugin-mkcert"
import icons from "unplugin-icons/vite"
import sentry from "@sentry/astro"
import mdx from "@astrojs/mdx"
import spotlightjs from "@spotlightjs/astro"
import { loadEnv } from "vite"
import { version, name } from "./package.json" assert { type: "json" }
const { SENTRY_AUTH_TOKEN } = loadEnv(process.env.NODE_ENV, process.cwd(), "")
// https://astro.build/config
export default defineConfig({
site: "XXXXXXX",
integrations: [
svelte(),
tailwind(),
mdx({
optimize: true,
}),
sentry({
dsn: "XXXXXXX",
environment: process.env.NODE_ENV,
release: `${name}@${version}`,
sourceMapsUploadOptions: {
project: "website",
authToken: SENTRY_AUTH_TOKEN,
},
}),
spotlightjs(),
],
markdown: {
syntaxHighlight: "prism",
},
i18n: {
defaultLocale: "de",
locales: ["de", "es"],
},
experimental: {
contentCollectionCache: true,
},
output: "server",
adapter: cloudflare(),
vite: {
server: {
https: true,
},
plugins: [
mkcert(),
icons({
scale: 1.2,
compiler: "svelte",
autoInstall: true,
}),
icons({
scale: 1.2,
compiler: "astro",
autoInstall: true,
}),
],
},
})
Steps to Reproduce
- Create new Astro Sentry setup with pnpm create
- Setup sentry
- Do a build
Expected Result
No build errors.
Actual Result
✘ [ERROR] Could not resolve "util"
node_modules/.pnpm/@sentry+node@7.86.0/node_modules/@sentry/node/esm/integrations/context.js:6:26:
6 │ import { promisify } from 'util';
╵ ~~~~~~
The package "util" wasn't found on the file system but is built into node. Are you trying to
bundle for node? You can use "platform: 'node'" to do that, which will remove this error.
Could not resolve "child_process"
About this issue
- Original URL
- State: closed
- Created 7 months ago
- Comments: 26 (15 by maintainers)
Commits related to this issue
- fix(astro): prevent sentry from externalized (#9994) Fixes https://github.com/getsentry/sentry-javascript/issues/9777 — committed to getsentry/sentry-javascript by anonrig 6 months ago
- fix(astro): prevent sentry from externalized (#9994) Fixes https://github.com/getsentry/sentry-javascript/issues/9777 — committed to getsentry/sentry-javascript by anonrig 6 months ago
- fix(astro): use correct package name for CF (#10099) Hopefully this fixes https://github.com/getsentry/sentry-javascript/issues/9777 — committed to getsentry/sentry-javascript by anonrig 6 months ago
@anonrig do you have further ideas?
For now, from my PoV, we’re aware that Astro+Sentry doesn’t work well on CF or Vercel Edge (which is why we also only guarantee that it works on Node-based server environments). If this is easily fixable, we can further investigate but full CF worker compatibility needs to be tackled when we choose to support Astro, Sveltekit, Remix, etc on None-node runtimes.
@muuvmuuv While in theory, this sounds very simple, it has a lot of downstream implications. We would like to preserve compatibility as much as possible and jumping 10 Node versions is not much of doing that.
My view on this is as follows: It’s fair to not allow non-prefixed runtime imports but there are consequences. E.g. libraries like Sentry not working. I don’t think we are doing anything wrong by not having the prefixes at this moment in time because we have compatibility to uphold. If downstream players disallow it, that is a tradeoff and all customers/consumers of these runtimes can decide on their own if they want to use the runtime that imposes these restrictions. Our Astro-intersected-with-Cloudflare customer base is likely not very large so I don’t think this is super high prio. We want to fix it, but it is not worth a major.
Yes we could add this fairly easily. Thinking of an API like this one: