@vanilla-extract/css dependency on chalk breaks deployment to Cloudflare Workers

[patryk-szydlowski]

Describe the bug

When building a project using vanilla-extract with vite and targeting cloudflare workers, there are Node-specific imports in the bundle (os, tty, process). CF workers are built on v8 and don't support these Node APIs. Tracking it down leads to this dependency on chalk: https://github.com/seek-oss/vanilla-extract/blob/0bc4e0a164e9167e0356557f8feee42d7889d4b1/packages/css/src/validateContract.ts#L17-L32

After removing dependency on chalk in the above file, these Node imports are not present in the bundle and it successfully deploys to cloudflare. Here is a hacky patch that got the build working:
https://github.com/patryk-szydlowski/solid-cloudflare-example/blob/d2eac8fd12eec98bbaec4590f35a3e9dae8d754d/patches/%40vanilla-extract%2Bcss%2B1.7.2.patch

Reproduction

https://github.com/patryk-szydlowski/solid-cloudflare-example/tree/983843b42533c9c18e72d063eae70fb90d048d2b

System Info

System:
    OS: macOS 12.4
    CPU: (10) arm64 Apple M1 Max
    Memory: 521.05 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 17.8.0 - ~/Library/Caches/fnm_multishells/33274_1658075735058/bin/node
    npm: 8.5.5 - ~/Library/Caches/fnm_multishells/33274_1658075735058/bin/npm
  Browsers:
    Brave Browser: 103.1.41.96
    Safari: 15.5
  npmPackages:
    @vanilla-extract/css: 1.7.2 => 1.7.2 
    @vanilla-extract/vite-plugin: 3.2.1 => 3.2.1 
    vite: 2.9.14 => 2.9.14

Used Package Manager

npm

Logs

patryk@Patryks-MBP solid-cloudflare-example % npm run start:prod 

> [email protected] start:prod
> solid-start start

🚧 'wrangler pages <command>' is a beta command. Please report any issues to https://github.com/cloudflare/wrangler2/issues/new/choose
Compiling worker to "/var/folders/_2/4ylx2qw96t39nh9w25sfkc740000gn/T/functionsWorker-0.7509164713623819.js"...
▲ [WARNING] Comparison with -0 using the "===" operator will also match 0 [equals-negative-zero]

    functions/[[path]].js:2510:16:
      2510 │   if (value === -0) value = 0;
           ╵                 ~~

  Floating-point equality is defined such that 0 and -0 are equal, so "x === -0" returns true for both 0 and -0. You need to use "Object.is(x, -0)" instead to test for -0.

▲ [WARNING] The CommonJS "module" variable is treated as a global variable in an ECMAScript module and may not work as expected [commonjs-variable-in-esm]

    functions/[[path]].js:1060:8:
      1060 │         module.exports = defaultOutdent;
           ╵         ~~~~~~

  This file is considered to be an ECMAScript module because of the "export" keyword here:

    functions/[[path]].js:7799:0:
      7799 │ export { onRequestGet, onRequestHead, onRequestPost };
           ╵ ~~~~~~

▲ [WARNING] Comparison with -0 using the "===" operator will also match 0 [equals-negative-zero]

    functions/[[path]].js:2510:16:
      2510 │   if (value === -0) value = 0;
           ╵                 ~~

  Floating-point equality is defined such that 0 and -0 are equal, so "x === -0" returns true for both 0 and -0. You need to use "Object.is(x, -0)" instead to test for -0.

✘ [ERROR] Could not resolve "os"

    functions/[[path]].js:1:23:
      1 │ import require$$0 from 'os';
        ╵                        ~~~~

  The package "os" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.

✘ [ERROR] Could not resolve "tty"

    functions/[[path]].js:2:23:
      2 │ import require$$1 from 'tty';
        ╵                        ~~~~~

  The package "tty" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.

2 error(s) and 2 warning(s) when compiling Worker.

Validations

• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[gkiely]

@patryk-szydlowski This library might work as an alternative. I think it safely checks for process.env and falls back to no color output.

I’m away from computer but will check when I get time.

https://github.com/alexeyraspopov/picocolors

[mattcompiles]

TBH I'm surprised chalk is the only issue running outside of a node environment. Other environments weren't considered originally when designing vanilla-extract. You could get around this by compiling your styles but not outputting CSS via the integration you're using.

Alternatively, I'm open to a PR to migrate to a non-node specific option. However, not sure how simple that'd be without creating a browser specific bundle which is a bit of a rabbit hole.

[pladaria]

I see that chalk library is included in our client bundles (webpack build). Is this expected?

And chalk (10kB) imports color-convert (25kB) and ansi-styles (4kB). None of this should be included in frontend code

[askoufis]

I see that chalk being bundled in our client bundles (webpack build). Is this expected?

@pladaria It shouldn't be. Is @vanilla-extract/css declared as a dev dependency in your app?

[pladaria]

@pladaria It shouldn't be. Is @vanilla-extract/css declared as a dev dependency in your app?

No, it was set as a regular dependency. I can change that but that shouldn't affect the webpack output. I will investigate

edit: After investigating, I saw that some components were using fallbackVar, imported from @vanilla-extract/css. This made webpack include chalk and its dependencies to the client bundles. After moving those fallbackVar usages to css.ts files, the problem was fixed.

[askoufis]

@vanilla-extract/[email protected] no longer depends on chalk, instead we depend on picocolors which works should work both in the browser and in cloudflare workers, though you will probably need to enable support for Node.js APIs.