Agnostic Runtime

[thescientist13]

Type of Change

Feature

Summary

Would like to provide Greenwood with the ability to run on a broad spectrum of runtime environments, not just NodeJS. So for example, being able to run Greenwood in

• NodeJS
• Deno (although technically Deno now support npm)
• Bun
• CloudFlare Workers
• etc

This means more Web APIs like fetch, URL, etc and less fs, path, etc. So would like to make the core as agnostic as possible through and through, in preparation for Serverless / Edge cases as per #1008 and #948 .

Details

Things to look out for would be what "Adapter" strategies for anything that is Node specific. This includes

• fs - alternatives to readFile, existsSync, copy, etc. Use fs.promises.* so we can use URL directly
• path - get rid of all instances
• process.cwd() - ???
• Readable.from
• Workers
• os

Also, will want to pull along WCC for this adventure too.

[thescientist13]

superseded by #1008

[thescientist13]

Still need this, separate from adapting for hosting platforms and providers.

[thescientist13]

So did some initial research on this by trying to "de" Node (🦕 ) WCC and while it seems path.join et al is mostly supplanted by URL now, the last big consideration I anticipated needing to solve for was fs. My hope was that fetch, introducing into Greenwood via #957 would supplant this.

However, it appears that file:// URI types are not in the fetch spec, left up to implementors to manage on their own.

For now, unfortunate as it is, file: URLs are left as an exercise for the reader. When in doubt, return a network error.

Thus, support for it is inconsistent

• ⛔ Node does not support it
• ⛔ node-fetch repo does not support
• ✅ Deno
• ❓ Bun - TBD
• ❓ Workers - TBD
• ⚠️ WINTERCG

So we may need to support runtime adapters in the short term it seems 🤕

---

Some other related links

• file:// protocol support sindresorhus/got#227
• Add support for file protocol (File URI Schema) JakeChampion/fetch#92
• https://bugs.chromium.org/p/chromium/issues/detail?id=810400

[thescientist13]

Seems like a conversation around a standard fs implementation is in the works over at the WinterCG.

[thescientist13]

Bun

Did a little testing with Bun 1.0. Got an error related to importing htmlparser

116 | async function trackResourcesForRoute(html, compilation, route) {
117 |   const { context } = compilation;
118 |   const root = htmlparser.parse(html, {
                   ^
TypeError: htmlparser.parse is not a function. (In 'htmlparser.parse(html, {
    script: !0,
    style: !0
  })', 'htmlparser.parse' is undefined)
      at /Users/owenbuckley/Workspace/project-evergreen/greenwood/packages/cli/src/lib/resource-utils.js:118:15
      at trackResourcesForRoute (/Users/owenbuckley/Workspace/project-evergreen/greenwood/packages/cli/src/lib/resource-utils.js:116:38)
      at /Users/owenbuckley/Workspace/project-evergreen/greenwood/packages/cli/src/lifecycles/prerender.js:121:10
      at /Users/owenbuckley/Workspace/project-evergreen/greenwood/packages/cli/src/lifecycles/prerender.js:107:37
      at /Users/owenbuckley/Workspace/project-evergreen/greenwood/packages/plugin-renderer-puppeteer/src/puppeteer-handler.js:19:18
      at /Users/owenbuckley/Workspace/project-evergreen/greenwood/packages/plugin-renderer-puppeteer/src/puppeteer-handler.js:13:23
      at processTicksAndRejections (:1:2602)

Made this change to the import and confirmed it worked in both Bun and Node and so was than able to succesfully build!

// before
import htmlparser from 'node-html-parser';

// after
import * as htmlparser from 'node-html-parser';

However, it looks like the serve and develop commands work, but just show a white page 🤔

[thescientist13]

npm specifiers are now available with Deno Deploy

[thescientist13]

Not sure we'll be able to get this in for 1.0, so deferring to 1.x milestone.

[thescientist13]

I think now with Deno 2.0 and Bun, I bet a lot of this is sorted out now with npm, and so aside from just prefixing everything NodeJS specific with :node I bet it might just work! 🤞

I think this item could still live on as a discussion to extricate the NodeJS parts at that point, but not sure how necessary it will be at that point.