[CDTOOL-691] Better error reporting when JavaScript tools are missing#1640
[CDTOOL-691] Better error reporting when JavaScript tools are missing#1640jedisct1 wants to merge 6 commits intofastly:mainfrom
Conversation
|
|
||
| usesWebpack, err := j.checkForWebpack() | ||
| if err != nil { | ||
| // Only verify toolchain when using default build (no custom [scripts.build]) |
There was a problem hiding this comment.
This could be an issue, since most (possibly all) of our JavaScript starter kits include a scripts.build property, and that means users using those starter kits won't benefit from any of this verification logic.
It may be possible to do the verification even if scripts.build is set, as long as its value is exactly npm run build which is what we have in the starter kits.
There was a problem hiding this comment.
Users of the starter kits should now benefit from it!
|
|
||
| Verify: npm --version | ||
|
|
||
| Then retry: fastly compute build`, |
There was a problem hiding this comment.
In each case where a 'retry' suggestion is provided we may need to do something more complicated, because the user may not have run fastly compute build - they may have run fastly compute publish or fastly compute serve, both of which internally run fastly compute build.
There was a problem hiding this comment.
Indeed! The help messages have been updated to be more generic.
jedisct1
force-pushed
the
jsruntimes
branch
2 times, most recently
from
3bf04e9 to
456d77b
Compare
Validate JavaScript toolchains before attempting a build, catching common setup issues early and providing accurate error messages instead of build failures. As Bun becomes increasingly popular, it’s not ideal to ask users to install Node when they already have Bun. So, this PR also adds proper support for Bun as an alternative runtime. The verification detects whether a project uses Node.js or Bun by checking for lockfiles, with support for Bun workspaces where the lockfile lives at the workspace root rather than in the subpackage. When something is missing, the error message now explains exactly what's wrong and how to fix it, whether that's installing a runtime, running npm install, or adding the @fastly/js-compute package.
As noted by @kpfleming: Most starter kits set scripts.build to "npm run build", which previously skipped all toolchain verification. Now we also verify when the build script matches known defaults like "npm run build" or "bun run build".
Build verification can also be triggered by "publish" or "serve", so telling the user to retry with "fastly compute build" is misleading. Suggested by @kpfleming, thanks!
2 participants
Change summary
Validate JavaScript toolchains before attempting a build, catching common setup issues early and providing accurate error messages instead of build failures.
As Bun becomes increasingly popular, it’s not ideal to ask users to install Node when they already have Bun. So, this PR also adds proper support for Bun as an alternative runtime.
The verification detects whether a project uses Node.js or Bun by checking for lockfiles, with support for Bun workspaces where the lockfile lives at the workspace root rather than in the subpackage.
When something is missing, the error message now explains exactly what's wrong and how to fix it, whether that's installing a runtime, running npm install, or adding the @fastly/js-compute package.
All Submissions:
New Feature Submissions:
Changes to Core Features:
User Impact
Use get better guidance and can use Bun as an alternative Runtime.
Are there any considerations that need to be addressed for release?
No breaking changes.