Build Image Update

[sidharthachatterjee]

DISCLAIMER: This a document intended for discussion and feedback. This is NOT a definite commitment to what we will deliver. All points below are subject to change. 

---

Overview

The current build image has been out of date for some time. We (the Pages team) would like to: 

• Upgrade the current build image
• Figure out a cycle of future updates
• Support as many versions as possible
  • Right now lots of languages like Python only support 3 specific ones, we want to expand this to any

---

Current V1

To start with, let's summarise the runtimes and tools (and their versions) we currently include: 

Operating System: Ubuntu 16.04 (xenial)

Runtimes

Language	Default version	Supported versions	Environment variable	File
Clojure
Elixir	1.7	1.7 only
Erlang	21	21 only
Go	1.14.4	Any version	GO_VERSION
Java	8	8 only
Node.js	12.18.0	Any version up to 17.x	NODE_VERSION	.nvmrc, .node-version
PHP	5.6	5.6, 7.2, 7.4 only	PHP_VERSION
Python	2.7	2.7, 3.5, 3.7 only	PYTHON_VERSION	runtime.txt, Pipfile
Ruby	2.6.2	Any version between 2.6.2 and 2.7.5	RUBY_VERSION	.ruby-version
Swift	5.2	Any 5.x version	SWIFT_VERSION	.swift-version
.NET	3.1.302

Tools

Tools	Default version	Supported versions	Environment variable
Boot	2.5.2	2.5.2
Bower
Cask
Composer
Doxygen	Version 1.8.6
Emacs	Version 25
Gutenberg	(requires environment variable)	Any version	GUTENBERG_VERSION
Hugo	Version 0.54.0	Any version	HUGO_VERSION
GNU Make	Version 3.8.1
ImageMagick	Version 6.7.7
jq	Version 1.5
Leiningen
OptiPNG	Version 0.6.4
NPM	Corresponds with Node.js version	Any version	NPM_VERSION
pip	Version corresponding with Python version
Pipenv	Latest version
sqlite3	Version 3.11.0
Yarn	Version 1.22.10	Any version	YARN_VERSION
Zola	(requires environment variable)	Any version from 0.5.0 to 0.14.0	ZOLA_VERSION

The goal of this RFC and the discussion it is to explore a list of runtimes and tools we'd like to support in the future. 

---

Proposed v2

Operating System: Ubuntu 22.04 (jammy)

Runtimes

Language	Default version	Supported versions	Environment variable	File
Clojure	1.11.1	1.11.1 only
Elixir	1.13	1.13 only
Erlang	25.0.2	25.0.2 only
Go	1.18	Any version	GO_VERSION
Java	17	Any version	JAVA_VERSION
Node.js	16.15.1	Any version	NODE_VERSION	.nvmrc, .node-version
PHP	8.1	Any version	PHP_VERSION
Python	3.10.5	Any version	PYTHON_VERSION	runtime.txt, Pipfile
Ruby	3.1.0	Any version	RUBY_VERSION	.ruby-version
Swift	5.6	Any version	SWIFT_VERSION	.swift-version
.NET	6.0.5	6.0.5 only for now

Tools

Tools	Default version	Supported versions	Environment variable
Boot	2.5.2	2.5.2
Bower
Cask
Composer	2.3.7
Doxygen	1.9.4
Emacs	27.1
Gutenberg	(requires environment variable)	Any version	GUTENBERG_VERSION
Hugo Extended	0.102.1	Any version	HUGO_VERSION
GNU Make	4.3
ImageMagick	6.9.11-60
jq	1.6
Leiningen	2.9.8
OptiPNG	0.6.4
NPM	Corresponds with Node.js version	Any version	NPM_VERSION
pip	Version corresponding with Python version
Pipenv	Version corresponding with Python version
sqlite3	3.39.2
Yarn	HELP WANTED - What Yarn version do you use?	Any version	YARN_VERSION
PnPM	7.x
wrangler2	2.0.15
Zola	0.16.1	Any version	ZOLA_VERSION
Embedded SaaS	(requires env var)	Any version or 1.54.5	EMBEDDED_DART_SASS_VERSION / EMBEDDED_DART_SASS

---

Version pinning

As you may have noticed, all the versions in v2 are pinned to a specific one. Pinning is important to always create a reproducible build. By default the output of your build should always be the same. Only installing the latest major (such as 16.x) would mean that between builds, the version can change. This version change can introduce a bug or cause an unintended side effect.

The only time we'll update the defaults is in two cases:

• A security vulnerability
• A breaking update (where we will increase the major version number e.g. 2 → 3)

Question for community: Is there any other scenario where you would expect an update to the default to be made? 

---

Deprecations

Deprecations will be done in a major version and removed in the next. For example, deprecating bower in v2 would mean removal in v3 if there are no major objections.

Question for community: How do you feel about the deprecation cadence? How would you like to be notified of deprecation?

---

Support

We're looking to have support remain for the last 2 major image versions for security updates. Note the latest major will be the one that receives new patch fixes, we are unlikely to backport many changes to the older version unless they're for security.

Question for community: Is the last 2 major image versions enough? Not enough? Too much?

---

Upgrade Cycle

We are thinking of releasing a new version of the build image every 6 months (not confirmed) in order for new versions to come out and new LTS' to be assigned. The upgrade cycle would only be for breaking changes, new versions being supported or new languages/tools (assuming no breaking change) would continue to be added at any time.

Question for community: How do you feel about the 6-month time frame?

---

Changes to the installations

• We're proposing to switch npm install to npm ci if a package-lock.json is present
  • This command is intended to be used in CI platforms such as Pages (https://docs.npmjs.com/cli/v8/commands/npm-ci)

---

What defines a breaking change?

A breaking change is something where projects may break. This could be updating the default version of a language/tool or updating the Operating System. This can also happen from doing something which seems harmless like updating the download location (this could lead to a currently supported version not being available for example) so all tests must pass to ensure things are not breaking unexpectedly.

Question for community: How does our definition align with your expectation of a breaking change? 

---

Summary of proposed changes

• Update default values (refer to #proposed-v2)
• Supporting as many versions as possible
  • Previously, some languages like PHP and Python were very limited. You only had 3 or so to choose from. We want to try and make most versions installable.
• Deprecated bower (do you use bower? If so, please tell us!)
• Deprecated cask (do you use cask? If so, please tell us!)
• Added pnpm
• Change npm install to npm ci if there's a package-lock.json

---

Final note

This RFC outlines our goals and the current plans, these may change due to new releases, technical limitations or other. We will try to keep this RFC as up to date as we can with what the image is looking like during development. User feedback will be critical in these early stages, so please reach out! We want to provide a great build experience for all types of developers, so all ideas/concerns are welcome! 

[isaac-mcfadyen]

Looks great!

One item of confusion in the community that often appears is around Yarn. Specifically, on the current build image Yarn is only available if a yarn.lock file is present. When people forget to commit this, they attempt to use Yarn and are confused when running yarn install fails with yarn: command not found.

A possible solution to this would be to include Yarn (and PNPM, from what the document above says) at all times, even when there is no lock file.

Another point of confusion is around the ability to customize the install command. Leaving it locked at npm ci might be difficult for some users as I've seen various comments around custom install commands and how npm install is (debatably, depending on workload) faster. The ability to customize the install command would be very welcome in these cases.

Final thing, and a lot of users seem to have expressed this in the Discord call, the ability to completely opt out of yarn and npm installs would be great since there are a lot of non-Node installation steps (I've seen Makefiles, Python scripts, and a lot of other things).

[WalshyDev]

A possible solution to this would be to include Yarn (and PNPM, from what the document above says) at all times, even when there is no lock file.

This is good feedback, I know it's a pretty common issue. I'll explore adding them by default :)

Another point of confusion is around the ability to customize the install command. Leaving it locked at npm ci might be difficult for some users as I've seen various comments around custom install commands and how npm install is (debatably, depending on workload) faster. The ability to customize the install command would be very welcome in these cases.

This may be out of scope for this initial work but I'd definitely welcome improvements in the future for this :)

Final thing, and a lot of users seem to have expressed this in the Discord call, the ability to completely opt out of yarn and npm installs would be great since there are a lot of non-Node installation steps (I've seen Makefiles, Python scripts, and a lot of other things).

Could you expand on this? I'm not sure exactly what is being proposed

[isaac-mcfadyen]

Could you expand on this? I'm not sure exactly what is being proposed

Sure! So some people might have a package.json or lockfile but not want to run an install command.

One example I can think of off the top of my head is people with a monorepo: they might have a package.lock at the root for coordination (so they can start multiple dev-servers at once, for example) but then want to run a non-node command within a folder in CI.

Basically, what I'm proposing is a toggle: "automatically run install commands" or similar. People who don't want install commands could just turn off this toggle and then run their custom command (makefile, python, etc) themselves.

[KianNH]

Would be cool if Rust was included in the build image - this would make it a lot easier to use something like https://rust-lang.github.io/mdBook/

See if you can tempt more JS devs to Rust :^)

[sidharthachatterjee]

I'm a big Rust user myself so I could definitely see value in including rustup and cargo if you'll are interested!

[KianNH]

It would also open up building Rust WASM (I.E workers-rs) if/when Functions supports WebAssembly

[WalshyDev]

Yes, Rust would definitely be good! I'll look into it :)

[itsezc]

Would be useful for deploying sites with Yew

[nilslice]

+1 to Rust!

[Cherry]

So excited to see this!

Is there any other scenario where you would expect an update to the default to be made?

Pinned versions makes 100% sense to me, other than in the case of a security issue. Users can still override versions with NODE_VERSION etc. env vars.

How do you feel about the deprecation cadence? How would you like to be notified of deprecation?

This makes sense to me. I'd expect a large notification in the build log, as well as something on the Pages project itself - perhaps a banner on the dashboard?

Is the last 2 major image versions enough? Not enough? Too much?

This seems great to me. If it's updated every 6 months, that means 1 year of security updates. As long as there's a clear notice in build logs and the pages project that any version I'm using is out of date, this sounds fine.

How do you feel about the 6-month time frame?

6 months feels fine to me. Notifications would need to be clear - build logs, pages project alerts, email notifications, etc., but updating once or twice per year is very approachable I think for any maintained project.

We're proposing to switch npm install to npm ci if a package-lock.json is present

This is a great change. There have been SO MANY supply chain attacks in JavaScript over the last few years, due to loose version numbers and npm install. Ignoring vulnerabilities, it’s also completely possible for a build to break from one install to the next, if package versions aren’t pinned.

Ideally, I'd love a way to one-click test a new image version, to verify it'll work with my project before upgrading, failing, and then reverting.

---

Open Source

This was discussed a bit on the community call, but what's the plan for open sourcing? An open source build image would be incredible for testing purposes, and guaranteeing the same build environment. Publishing the image on Docker Hub without open sourcing would be a step in the right direction, but with other competitors entirely open sourcing their image, the Pages one being open source would be awesome to see, and add a massive layer of confidence. Adding your own logs, changes, etc. to the image for very intricate and edge-casey testing would be great, as well as just having a great source for issues, suggestions, etc.

Given the nature of Pages, the competition, and the fast moving ecosystems it supports, I think not open sourcing and actively maintaining a repository with issues/discussions, releases, etc. would be a mistake.

[WalshyDev]

Ideally, I'd love a way to one-click test a new image version, to verify it'll work with my project before upgrading, failing, and then reverting.

Yes, we want to make the version changeable on both prod + preview that way you can test it in preview and if happy deploy to prod :)

As for open source, I share your view that we should do that. Definitely keep an eye out.

[rijnhard]

having a docker image would be super useful so that you can develop locally on the closest possible env to production. especially for testing builds.
I just spent a saturday fixing differences in local and Cloudflare pages.

[isaac-mcfadyen]

For notifying about deprecations: one possible thing that might make sense is replacing a script with a shell-script right inside the build image.

For example, if I tried to use bower it would echo (to the build logs, maybe halting things?) bower has been deprecated from version x onwards. If you would like to use bower, go to Settings -> Version and rollback to version x.

Another thing that would be great would be build image changelogs, similar to the Workers changelogs but perhaps more automated?

[WalshyDev]

Yep, adding a deprecation warning seems good. I'm not sure exactly how we'd go about it, it'd likely need to just always be there as we can't detect you using it.

Another thing that would be great would be build image changelogs, similar to the Workers changelogs but perhaps more automated?

We will definitely have a changelog and it will definitely be automated (if not right away, shortly after) :)

[kotx]

Can node version be extracted from package.json's engines field as well? Although, it can specify general requirements for node (e.g. >13, <0.12), not the specific version requirement, so this could be difficult.

[WalshyDev]

I looked at this but I don't think we can easily do it :/

Defining >= 14.4 could install only 14.4 or something but it's also kinda awkward to parse this string. Considering we already have 3 ways to change the version, I think it's good we leave it there.

[GregBrimble]

There's been a bit of discussion on Discord already, so to not lose that, I'll link it here. But please continue to post comments and questions on this RFC :)

[its-jman]

My question in the call regarding expanding the build service to support workers as well, the other reason I bring this up is supporting custom images.

If you support custom images, many of these questions and challenges about the new build image would be simplified since in the worst case they can use custom.

While those builds might be slower at the beginning, this would help identify the most common requirements which could be put into any number of cached/default images.

[williamhorning]

I'd really like to see docker in the build image, as it would allow for loads of tools to run on Pages. Also build caching would be a HUGE improvement if it were added into the build image.

[WalshyDev]

Can you explain your use case for us including Docker?

[williamhorning]

Can you explain your use case for us including Docker?

My thinking was that if a tool were to be deprecated and removed from the image, that you could use docker to continue using that tool. You could also use Docker to run versions of tools that aren't supported in the build image (like other versions of .NET or super old versions of software)

[WalshyDev]

This doesn't feel like a good user experience and doesn't seem like something we should encourage. I'd rather just try and support the version or they could use an older build image until they're ready to update.

[gregmartyn]

It'd let us avoid this whole problem in the first place of the Cloudflare image being behind. We could be using our own image instead, with e.g. CentOS and a beta release of Node if we wanted. Most other CI environments I've worked with use docker.

[dantewang]

The Zola version support in V2 is still "Any version from 0.5.0 to 0.14.0“ but Ubuntu 22.04 should support 0.15.3 I guess. However, the delay between 0.14.0 and the support of 0.15.3 (0.15.3 is already out for almost 6 months) may be a huge problem for people using this tool.

[WalshyDev]

Hey, I haven't updated the range there but we will definitely support the latest version and try to go back as far as the current default. I will update the doc when I have more info on that.

[dantewang]

@WalshyDev Thank you! I'm currently using Hugo on CF Pages, but I plan to migrate to Zola. I'll wait for the update!

[maxhoffmann]

Yes, it would be great if Cloudflare finally supports the current version of Zola. 🙏

[dantewang]

@WalshyDev Is there an esitmated date when we can see the new image being used?

[brycewray]

Thanks for putting this before the community! Two thoughts:

• Hugo has added a lot of improvements since 0.89.4 (especially in the following version, 0.90.0), so I’m curious about why that particular version is the one suggested for the updated build image. As of this writing, the current is 0.101.0.
• Also re Hugo, it would be tremendously helpful if one could specify addition of the Embedded Dart Sass binary — perhaps through an env var (e.g., EMBEDDED_DART_SASS), much as one now can call a specific version of Hugo rather than the build image default.

cc: @bep

[i40west]

the highest one I found from a quick search

Hugo releases are only announced on Github at the moment. That page is drastically out of date. https://github.com/gohugoio/hugo/releases

Having said that, the releases come pretty frequently, so assuming you want a stable default version, we will likely continue to need to always specify HUGO_VERSION anyway.

I'm a Hugo noob

The only reason to ever use non-extended Hugo is if you don't want to, or can't, build it with the extra dependencies.

[bep]

@i40west @brycewray is right. And you really want to use the extended version. The only reason we have two versions is that we don't have a build/release setup for all OSes for the extended version (e.g. we currently do not build the extended version for OpenBSD etc.).

[WalshyDev]

Thank you all for the answers! :)

I have updated the RFC to use Hugo Extended 0.101.0, I will also take a look at the saas binary.

[leegold]

@WalshyDev I'm a huge +1 for Hugo Extended. At the moment many (most?) Hugo themes used in many (most?) Hugo sites depend on Hugo Extended for Sass support, and that means it narrows down Hugho instances to a small subset of the ecosystem.

[creslinux]

I ran into the hugo vs hugo extended today on CF - I'd switch themes, all the work local on extended, site looks great etc
When pushed to git cf automation failed the build

Is there are way to beta-test hugo extended with CF ?

[ghost]

Current SQLite is Version 3.39.0 (2022-06-25)

[Yrlish]

Will you be reading environment variables from .env or does they need to be put manually into the GUI?

[WalshyDev]

Right now there are no plans to read from .env

You shouldn't commit that file so would this be a .env with no secrets or how do you want it to be populated?

[Yrlish]

It was more of a thought to being able to centrally control all the *_VERSION variables from within the repo. Also allowing for separate branches to have different versions. Like doing a major (break-changing) upgrade of something in a branch and to test deploy it.

[WalshyDev]

Ah I see, yeah we're looking at a config file where you can control versions :)

we will also be allowing the image version to be changed per env (so prod and preview)

[brycewray]

Ah I see, yeah we're looking at a config file where you can control versions :)

we will also be allowing the image version to be changed per env (so prod and preview)

That would be great! With items that change frequently (like Hugo versions, to use my earlier example), it's far easier to change within a repo file than having to go back into the GUI, especially since that's two entries — production environment and preview environment.

[itsezc]

Would love to see BunJS added to the supported runtimes.

[itsezc]

Ideally both, but building would be a great place to start

[WalshyDev]

Building, ok that's easy to do.

Functions... not really possible. Workers run in a V8 isolate and Bun is it's complete own runtime on top of JSC.

[isaac-mcfadyen]

For reference:
JSC = JavaScriptCore (Safari)
V8 = V8 (Chrome)

Not really compatible since they're completely seperate runtimes and Workers (and Functions) have been built on V8.

[itsezc]

Thanks, just looked into the differences between v8 and JSC; would still love to see the ability to build with Bun, I have a few projects that use Next with Bun that I'd like to deploy on Pages.

(I'm aware I can use Node, just prefer the faster build times with Bun).

[itsezc]

@WalshyDev has there been any progress with Bun? I think it's grown rapidly the past few months and deserves to be in the build image, would love to hear your thoughts on it.

[DaniFoldi]

With the current build image being referred to as v1, and the new one as v2, I think a better long-term solution is needed to version the images.
Think about this scenario: I have a Pages project that I haven't touched for a year or two (why not), and I'm not a community champ to know the docs by heart. Now that I want to update my project - including the build image - how old is version say 8? I see that 10 is the newest, but just how new? Will 11 drop tomorrow or in 3 months?

A breaking update (where we will increase the major version number e.g. 2 → 3)
So while semver would dictate using integers for versioning the image, I propose that some kind of date-aware versioning system is used instead.

Real life example: if you've heard about ubuntu once, you'll recognise 22.04. Now try to think about which version of CentOS you would use if you had to - 7, 8, 9, or is there a new one? Definitely requires a docs read to decode.

To avoid confusion with ubuntu versions specifically, I'd avoid the YY.MM format and use something else, like YY-MM, or YYYY-MM. That's good for another few thousand years, since I mentioned "long-term" anyways.

[helloimalastair]

This is mainly about the build image but also Pages in general. Could Pages' configuration be unified in one file, preferably one with a format that can have type completion(think *.config.ts, but doesn't have to be any specific format, just an idea)? It seems odd that every new feature has its configuration, with a format that doesn't always match what the others are doing. This could also be handy for setting up build tool/framework detection since the config file would be able to tell you out of the box what frameworks are supported and how exactly to set a version for them.

Here's a proposal for what that could look like that I bashed together in a few minutes. Could probably be improved, but it is just a proof of concept. https://gist.github.com/helloimalastair/a431840311f78a104e03bce945ecbd8c

[DaniFoldi]

I couldn't find this mentioned earlier, please pardon me if it has been and I'm blind. asdf is a version manager for tools (think nvm, for more than node), and it's compatible with a lot of shell environments already, which would be helpful for people keeping their local versions in sync with what is used for building. And it has backward compatibility with e.g. .nvmrc and other similar files.

https://asdf-vm.com

[Comver]

It would be better if we could have the build file like netlify.toml, so the devs can manage the build settings.

[Vysp3r]

Any news regarding a possible release date so we can finally use newer versions of Node?

[drwpow]

The current LTS version of Node, v18, has been out for almost a year and we still can’t use it. In a matter of months, v16, the only LTS version supported by Cloudflare, will be end-of-life. An update is needed soon!

[WalshyDev]

We know. We didn't expect it to be this long. We use Pages just like all of you and feel the pain ourselves. It's coming is all I can say right now.

[mkasprzyk]

@WalshyDev Does something changed in the last month? Can we expect support for node 18 in next weeks/ month?

[Yinchie]

@WalshyDev Does something changed in the last month? Can we expect support for node 18 in next weeks/ month?

Wondering same. For now, I switched to another service for my website that does support the latest stable tech.

[aozaki-kuro]

Good to know the building image would have a major update soon (hopefully).

Since pnpm will be supported, would it be also possible to save the build cache / dependencies for faster build?

Currently the process have to pull all dependencies every time. While on Vercel and Github Actions, dependencies even build cache can be saved and reused for the next build, unless you manually clear it / select to build it clean.🤔

--

Edit:

My personal blog (Next.js w/ pnpm, around 30 pages in total) takes around 1m40s on Cloudflare Pages while it takes only 30-40s on Vercel. Even with Github Actions, it only took 1m from environment initiating to upload complete.

I love Cloudflare services, but Cloudflare Pages' building image really needs way more improvements.

[CanRau]

I'm pretty happy using GitHub Actions to deploy to CF Pages, which also gives me more flexibility and control

[Vysp3r]

It's a concerning precedent, honestly. I don't know if I'm comfortable using it once it's updated at this point. What if they just abandon the build image again in the future and we have to migrate away (again...) to continue building our projects?

That's a good thing to consider indeed...

[eerison]

I'm pretty happy using GitHub Actions to deploy to CF Pages, which also gives me more flexibility and control

Yep deploy via github actions is quite amazing alternative and it give us a lot of control 😀

[aozaki-kuro]

Well seemed like "caching" is such an ancient topic... pnpm is also something expected for sooooooo long and even Netlify supported pnpm natively in Oct 2022 (after being asked for years).

Oh btw I have migrated to build on Github Actions several days before (I can host my own runner anyway) and then push it to Cloudflare Pages. That's way better than the current building image.

[CanRau]

Also you get the whole ecosystem of actions and can use pnpm and whatever else you need 🤗

[nilsbunger]

I also just realized we are better off deploying via Github Actions since we have to install an extra binary (libvips) for our build.

[jauderho]

Depending on how frequently the image is updated, certain runtimes may have to be updated more frequently. For example, Go 1.18 has already reached EoL as of a week ago. See https://endoflife.date/go

[marketsystems]

was going to give cloudflare pages a try... failed at the first hurdle of not supporting node 18... oh well off to a decent provider then :D

[CanRau]

highly recommend using GitHub Actions anyway

[yw662]

It should support node 18 because node 16 is end of life. However currently I don't think there could be sth preventing you from using nodejs 16.

[shinebayar-g]

It's not EOL yet. https://nodejs.dev/en/about/releases/ But there are definitely packages requiring Node 18 only lol.

[yw662]

From the release notes of node 17 and 18 I doubt whether there really are.

[marketsystems]

Yesterday as a test I tried pushing the same nextjs git project to aws amplify, vercel, netlify and cloudflare pages.. worked fine deployed and visible with no hassle on all but cloudflare pages. (tiny project and started off with a bunch of server errors, eventually got round those only to run into the CPU limit on a 4 page site!) Not top of the list for sure...

[CanRau]

sounds like you might be using nodejs specific stuff most of which aren't supported in the Workers runtime.
Workers and therefore Pages aren't directly comparable completely with those other offerings

[marketsystems]

No, i set them all as edge-runtime first

[AlloryDante]

When is v2 gonna be released? Tried to deploy a Sveltekit app and it requires node 18....At least is there any workaround?

[MihaiVoinea]

Could you enable it for dev-hiringflow.pages.dev, please? Thanks!

[jrf0110]

@MihaiVoinea opted in. If you have any issues, please post in the discord channel https://discord.com/channels/595317990191398933/1083706984949358692

[JaspervRijbroek]

@veroohh @jrf0110 Mine is jaspervrijbroek-github-io.pages.dev I would love to test drive it :D

[hckhanh]

Hi @jrf0110, Can i opt-in to node 18 now?

[jrf0110]

Hey @hckhanh node 18+ is now available generally to all users. So indeed, you can use it by setting by setting the NODE_VERSION env variable to the value 18 or by specifying it in your .nvmrc

[salexpro]

Waited for more than half a year, switched to Vercel

[Vysp3r]

I did not switch to Vercel, but yeah I did switch too sadly.

[marketsystems]

Amazing how these big companies cannot seem to get their act together, must be either low takeup of pages or low priority for cloudflare! Either way everybody will just migrate to alternatives
Should be obvious surely to keep supporting the latest stable versions soon after release

[danbulant]

Welcome to "let's base our image on old LTS ubuntu" moment

[dantewang]

A comment from last year shows that their whole team put this aside to work on the Pages Functions GA. So this seems to be pretty low priority for them, which can be easily interrupted by anything that looks "cool" to new users.

[mrsarm]

I can't believe it does not support Node 18 yet, the active LTS, I would like to switch to Vercel as well, but we're stuck with Cloudflare, that looks like it's in pilot mode in terms of updates and new features.

[cmmartin]

Having your own CLI (wrangler) in package.json breaks your pages deploys

[WalshyDev]

It shouldn't, can you join the Discord and open a thread in #pages-help
https://discord.gg/cloudflaredev

[cmmartin]

I've already fixed it by simply removing wrangler from my package.json. wrangler requires a more recent version of node.js and pages is building with version 12. Node LTS is v18 now.

[eerison]

IMO he should create threads in github discussion, because it could be a problem for other guy, and it gonna be documented.

[muzhig]

@cmmartin you can define NODE_VERSION env variable, versions up to 17 are supported, and this might solve your problem.
https://developers.cloudflare.com/pages/platform/build-configuration/#language-support-and-tools

[Steveantor]

Do u support NodeJS 18 by any chance?
cause when our .nvmrc file added the NodeJS 18 version,
the Cloudflare log showed that it's using Node 18xx for building.
The post and doc say that v1 supports NodeJS versions up to 17xx.

Attempting node version 'v18.14.0' from .nvmrc
Downloading and installing node v18.14.0...
Downloading https://nodejs.org/dist/v18.14.0/node-v18.14.0-linux-x64.tar.xz...
Computing checksum with sha256sum
Checksums matched!
Now using node v18.14.0 (npm v9.3.1)

[jrf0110]

@jprinaldi you hit the nail on the head. That is exactly what has happened 🥇

[yw662]

@jrf0110 It must have been difficult with so many eyes on you guys hmm :-). It is the whole "image v2" thing or is it just node v19 ?

[yw662]

And...would it be safe now to switch NODE_VERSION=18 to NODE_VERSION=lts/* ?

[rohanrajpal]

Node 18 is getting recognized as expected! But it didnt detect pnpm :( Is the support yet to be added for pnpm?

[claughinghouse]

Node 18 is getting recognized as expected! But it didnt detect pnpm :( Is the support yet to be added for pnpm?

Add pnpm to devDependencies until the bug is fixed.

cloudflare/next-on-pages#52 (comment)

[GregBrimble]

Hi folks! Thank you for your feedback in this thread — it was very valuable as we considered what to update with. We're very excited to announce that a v2 beta for Pages' build system in now available to select in your project settings and it comes with a fresh set of defaults, including Node.js 18, pnpm support and Python 3.10! More information is available on the blog post (https://blog.cloudflare.com/moderizing-cloudflare-pages-builds-toolbox/) and documentation (https://developers.cloudflare.com/pages/platform/language-support-and-tools/).

Please give it a try and let us know if you have any feedback in the #⁠pages-build-system-v2-beta channel in Discord!

And if you have any questions, we're going to be hosting a Q&A session later today in Discord at 1730 UTC: https://discord.com/invite/cloudflaredev?event=1103324690149298196. Hope to see you there!