-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: change access-api wrangler.toml to be no_bundle=false. use wrangler bundling #739
Conversation
|
||
[vars] | ||
ENV = "dev" | ||
DEBUG = "true" | ||
DID = "did:web:local.web3.storage" | ||
PRIVATE_KEY="MgCYWjE6vp0cn3amPan2xPO+f6EZ3I+KwuN1w2vx57vpJ9O0Bn4ci4jn8itwc121ujm7lDHkCW24LuKfZwIdmsifVysY=" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same value from repo /.env.tpl , so it is already public
|
How I tested this:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is good. Comments inline but nothing blocking, so approving this on the assumption you will tweak or explain as required.
working-directory: packages/access-api | ||
run: | | ||
# write ./dist/index.{js,js.map} | ||
pnpm exec wrangler --env="$ENV" publish --dry-run --outdir=dist |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my assumption here is that the step before should already generate these as part of the wrangler action. I'd feel more comfortable here if the artefacts are build once and then sent to the places they need to go, rather than relying on the build definitely always being reproducible (it should be, but, if why tempt fate in our error reporting)
what does SENTRY_UPLOAD
do in that previous step? is it unused, or does wrangler-action actually upload a thing to sentry (that would be surprising)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does SENTRY_UPLOAD do in that previous step? is it unused, or does wrangler-action actually upload a thing to sentry (that would be surprising)
Nothing atm. (because now wrangler.toml
doesn't define a custom build command that might read it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my assumption here is that the step before should already generate these as part of the wrangler action.
Good suggestion. I had thought so too, and tried that, but iirc it didn't write the files.
Let me see if it's just because I need to pass --outdir=dist
on the previous non-dry-run publish.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a commit to only invoke wrangler publish
once (via wrangler-action
with custom command to pass --outdir dist
) 3af1c35
async function main(argv = process.argv) { | ||
const cli = sade('access-api-release') | ||
cli | ||
.command('name', '', { default: true }) | ||
.option('--env', 'Environment', process.env.ENV) | ||
.action((opts) => { | ||
const releaseName = getReleaseName(opts.env) | ||
console.log(releaseName) | ||
}) | ||
cli | ||
.command('esm', 'print release info as ES Module string') | ||
.option('--env', 'Environment', process.env.ENV) | ||
.action((opts) => { | ||
const lines = [ | ||
`/** @type {string|undefined} */`, | ||
`export const gitRevShort = '${git.short(__dirname())}'`, | ||
`/** @type {string|undefined} */`, | ||
`export const name = '${getReleaseName(opts.env)}'`, | ||
] | ||
console.log(lines.join('\n')) | ||
}) | ||
cli.parse(argv) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is neat, but note that our other projects do this by injecting these in as variables into the bundle at build time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They do that using no_bundle=true
and injection via custom esbuild, so this is a way of doing it with no_bundle=false
.
Yes it's different, but it seems worth it in order to get the stack traces.
If there's another way that works that seems better, lmk and I can try to implement.
packages/access-api/wrangler.toml
Outdated
rules = [ | ||
{ type = "Text", globs = ["package.json"], fallthrough = true } | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what dis?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this was required for cloudflare workers to be able to import
the package.json, which
I think it's a bundler-independent way of providing enough information about whether importing from that json file should result in a string Text
or a json-parsed object.
https://developers.cloudflare.com/workers/wrangler/configuration/#bundling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I need it anymore, since now release.node.js imports it in node at build time, and writes a rendered value for cloudflare to import via ESM (so it doesn't need to import the package.json to build the rendered version).
I'll remove it
@@ -28,43 +25,52 @@ database_id = "7c676e0c-b9e7-4711-97c8-7b1c8eb229ae" | |||
[[r2_buckets]] | |||
binding = "DELEGATIONS_BUCKET" | |||
bucket_name = "w3up-delegations-dev-0" | |||
preview_bucket_name = "w3up-delegations-dev-0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some changes in this file seem unrelated to bundling / getting stack traces to work. not a blocker, but can you confirm why these changes are needed in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one was suggested by wrangler
cli when I was deploying to dev
env. The dev
env has been usused for a bit, so I think we just hadn't exercised that path, so this makes sense as an addition that makes deploying to dev better (seemingly unrelated to d1/sentry/bundling, but the relationship is that the dev env is useful for testing deployments/new-code without disrupting staging, so it was useful here, and is probably useful to commit so others dont run into it when they try to use dev env + wrangler
)
🤖 I have created a release *beep* *boop* --- ## [6.1.0](access-api-v6.0.0...access-api-v6.1.0) (2023-04-14) ### Features * change access-api wrangler.toml to be no_bundle=false. use wrangler bundling ([#739](#739)) ([d659516](d659516)) ### Bug Fixes * access-api cli.js build does sourcemap=external instead of true ([#731](#731)) ([d1a35b7](d1a35b7)) * add /.debug/error route ([#732](#732)) ([2ca5de8](2ca5de8)) * change access-api src/index.js 'export default' to be an immediately-defined object in hopes stack traces will work better ([#733](#733)) ([a509313](a509313)), closes [#623](#623) * toucan-js in access-api does not use RewriteFrame integration ([#729](#729)) ([eeb90e6](eeb90e6)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Motivation:
no_bundle=true
along with d1.Experiment
release
calledbengo-dev-0
sentry errors hereGET /.debug/error
no_bundle=false
(or omittingno_bundle
) is incompatible with wrangler d1 bindingsFindings:
access/authorize
handler. That worked fine, and I got an email from dev env. The error happened when I clicked the email (invokingaccess/confirm
), when theaccess/confirm
invoacation handler tried to write to d1dev
doesn't have latest migrations applied that created that table. So I provisioned a new d1 database for this dev env, and rannpx wrangler --env=dev d1 migrations apply __D1_BETA__
. This would error every couple migrations, but if I re-ran it it would make progress and error again (Internal error [code: 7501]
), but eventually it would succeed at all migrations.access/claim
(reads from D1), and got no error all the way through invoking from second device