refactor: use esbuild "file" loaders to add runtime files to the published assets #860
Conversation
petebacondarwin
requested review from
GregBrimble and
threepointone
as code owners
🦋 Changeset detectedLatest commit: e6c3c60 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.developers.workers.dev/runs/2250030696/npm-package-wrangler-860You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.developers.workers.dev/prs/860/npm-package-wrangler-860Or you can use npx https://prerelease-registry.developers.workers.dev/runs/2250030696/npm-package-wrangler-860 dev path/to/script.js |
petebacondarwin
force-pushed
the
runtime-assets
branch
3 times, most recently
from
b37204e to
1519b10
Compare
…ished package When esbuild builds Wrangler, it creates a new directory "wrangler-dist", which contains the bundled output, but then any `__dirname` or similar Node.js constant used in the code, is relative to this output directory. During testing, Jest does not bundle the code, and so these `__dirname` constants are now relative to the directory of the original source file. This is a refactor that ensures consistency in the access of runtime files between production and test environments, by implementing build/test time transforms. In esbuild we use a "file" loader that will not inline the content of the imported file into the bundle, but instead copy the content to the output directory, and then return the path to this file in the code. We can then use this value to load the content at runtime. Similarly, in Jest testing, we have a custom transform that will return the location of the original file (since there is no real output directory to copy the file to). The result of this change, is that we can just ensure that the paths in the source code are relative to the source file and not worry about where the generated code will be output. Further we are able to remove a bunch of files from the package that we publish to npm.
petebacondarwin
force-pushed
the
runtime-assets
branch
from
1519b10 to
e6c3c60
Compare
There was a problem hiding this comment.
The reasoning is good, but I don't like the implementation of using require to instead inline the path to the file. It's confusing if you read it and you don't know what's going on. Instead, I recommend making a new virtual module (say, wrangler-template-paths) that exports an object to these paths.
import paths from 'wrangler-template-paths';
paths['new-worker.template.js']; // /asbolute/path/to/new-worker.template.js
// etcImplementing this would be an esbuild plugin that captures imports to wrangler-template-paths and sends an object with those paths as its content. What do you think?
|
Is your concern the use of |
|
The concern us around using Here's another alternative - pathToTemplateFile('path/to/new-worker.ts'); // where `pathToTemplate` is a magic global function that works in our codebase^ If this would desugar to a |
There was a problem hiding this comment.
This is a great improvement not just on pathing but how we bundle files we need i.e. templates
If it is not already done I will close the PR that I started to initially handle the pathing for pages template, this PR handles that and more!
Edit: Provisional to Greg's approval as well as resolution in conversation pertaining to functional abstraction pathToTemplate
|
This PR is very stale and not likely to land soon as it has limited impact and requires more discussion. |
No description provided.