-
Notifications
You must be signed in to change notification settings - Fork 86
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: use Frameworks API #2547
base: main
Are you sure you want to change the base?
feat: use Frameworks API #2547
Conversation
… able to use either previous setup with regional blobs or just legacy blobs
📊 Package size report 0.06%↑
Unchanged files
🤖 This report was automatically generated by pkg-size-action |
export async function uploadBlobs(ctx: FixtureTestContext, pluginContext: PluginContext) { | ||
if (pluginContext.blobsStrategy === 'frameworks-api') { | ||
const files = await glob('**/blob', { | ||
dot: true, | ||
cwd: pluginContext.blobDir, | ||
}) | ||
|
||
const keys = files.filter((file) => !basename(file).startsWith('$')) | ||
await Promise.all( | ||
keys.map(async (key) => { | ||
const { dir, base } = parse(key) | ||
const metaFile = join(blobsDir, dir, `$${base}.json`) | ||
const metadata = await readFile(metaFile, 'utf-8') | ||
.then((meta) => JSON.parse(meta)) | ||
.catch(() => ({})) | ||
await ctx.blobStore.set(key, await readFile(join(blobsDir, key), 'utf-8'), { metadata }) | ||
}), | ||
) | ||
await Promise.all( | ||
files.map(async (blobFilePath) => { | ||
const { dir: key } = parse(blobFilePath) | ||
const metaFile = join(pluginContext.blobDir, key, `blob.meta.json`) | ||
const metadata = await readFile(metaFile, 'utf-8') | ||
.then((meta) => JSON.parse(meta)) | ||
.catch(() => ({})) | ||
await ctx.blobStore.set( | ||
key, | ||
await readFile(join(pluginContext.blobDir, blobFilePath), 'utf-8'), | ||
{ | ||
metadata, | ||
}, | ||
) | ||
}), | ||
) | ||
} else { | ||
const files = await glob('**/*', { | ||
dot: true, | ||
cwd: pluginContext.blobDir, | ||
}) | ||
|
||
const keys = files.filter((file) => !basename(file).startsWith('$')) | ||
await Promise.all( | ||
keys.map(async (key) => { | ||
const { dir, base } = parse(key) | ||
const metaFile = join(pluginContext.blobDir, dir, `$${base}.json`) | ||
const metadata = await readFile(metaFile, 'utf-8') | ||
.then((meta) => JSON.parse(meta)) | ||
.catch(() => ({})) | ||
await ctx.blobStore.set(key, await readFile(join(pluginContext.blobDir, key), 'utf-8'), { | ||
metadata, | ||
}) | ||
}), | ||
) | ||
} | ||
} |
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 entire function doesn't seem like should be implemented here (as in in next-runtime repo) as it does reimplement file-based blobs uploads (something which ideally could be imported from ~netlify/build and just used) - now it "has to" support different implementations (when moving to regional blobs it was only directory change, but frameworks api also has updated directory structure).
This is not the biggest deal because it's quite straight forward - but maybe something to keep in mind in case ~integration kind of tests would be introduced in other repos to avoid duplicating something like that
@@ -184,7 +184,7 @@ export async function runPluginStep( | |||
// EDGE_FUNCTIONS_DIST: '.netlify/edge-functions-dist/', | |||
// CACHE_DIR: '.netlify/cache', | |||
// IS_LOCAL: true, | |||
// NETLIFY_BUILD_VERSION: '29.23.4', | |||
NETLIFY_BUILD_VERSION: '29.50.5', |
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 makes integration tests use Frameworks API code paths - because integration test setup rely on PluginContext
already when looking for serverless and edge functions to bundle and invoke them, this almost doesn't need any additional changes other then adjustment to simulating file based blob uploads.
Is there value in trying to run integration tests vs multiple netlify/build version? I don't think it does given that we implement lot of integration/test setup ourselves, but doesn't hurt to ask for other opinions here.
I did add one ~kitchen-sink e2e test to run on ~older CLI implicitly testing blobs, serverless and edge functions as a way to at least have some ~smoke test to have some defense against regressions there in future, but it's pretty minimal
…765-migrate-next-runtime-to-use-frameworks-api
…765-migrate-next-runtime-to-use-frameworks-api
…765-migrate-next-runtime-to-use-frameworks-api
Description
work in progress on migrating next runtime to use frameworks API. It still will support older method to support cases of CLI usage (which user might not updated)
Documentation
Tests
You can test this change yourself like so:
Relevant links (GitHub issues, etc.) or a picture of cute animal