Uri.base is broken on Node.js

[nex3]

Currently Uri.base doesn't work in many situations when compiled Dart code is run on Node.js. It uses global.location, which is undefined in Node.js. The preamble tries to work around this by shoving a path into a file: URL, but this is invalid in general. It breaks in all cases on Windows, and will break on POSIX systems if the path contains characters that need to be percent-escaped.

This is an issue for both DDC and dart2js.

[nex3]

One possible way to do this would be to have Uri.base()'s JS implementation try to call process.cwd() on Node and use new Uri.file() to properly convert that to a URL.

[nex3]

This is causing real-world breakages for Angular users in the wild (see sass/dart-sass#734). Can it be prioritized?

[kevintruby]

This is also appears to be the cause of an odd SSR issue when working with Vue CLI 3 single-file components. In my use case, also trying to compile SCSS directly from components via webpack and the sass npm module, which is a distribution of Dart Sass.

Returns the following:

> vue-cli-service build


⠧  Building for production...

 ERROR  Failed to compile with 1 errors                                                                                                                                               1:47:15 PM

 error  in ./src/components/Breadcrumb.vue?vue&type=style&index=0&id=352a2dd2&lang=scss&scoped=true&

Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/sass-loader/lib/loader.js):
Unsupported operation: 'Uri.base' is not supported

It's been really difficult finding help on this issue, and would love to get more info 🙂

[molszanski]

I've also faced issues with SSR.

Managed to duct-tape it with with this code in our setup-for-ssr.js

 global.location=  {
   href: "file://"+process.cwd()+"/"
 };

[nex3]

@molszanski Be aware that file paths are not substitutable for file: URLs in general. There are many edge cases that work differently between them, particularly on Windows, so that code will break in some situations.

[molszanski]

@nex3 Thank you Natalie for the heads up! I've read your comments and warnings. Appreciate them a lot! Luckily I can get away with this hack for now. But this will come back and bite me one day.

[nex3]

This breaks even more badly when the Node.js environment is using jsdom, which is common in test environments. jsdom configures window.location.href to simulate a browser environment, which overrides the preamble's (already-hacky) replacement and makes Uri.base look like it's operating in a browser when in fact it's not.

Once again, this is affecting real-world users. Can we please prioritize this issue?

[birdofpreyru]

I've stumbled across this bug yesterday, it is fun to learn that the problem is known for 6 years, and it is not patched yet 😀 Many thanks for suggesting to set global.location.href to URL based on process.cwd(), that saved my day! 🎉

As it is mentioned above that the following is fragile

global.location = {
  href: `file://${process.cwd()}/`,
};

I decided to mention here that this variation might be more bulletproof, at my first glance:

const { sep } = require('path');
const { pathToFileURL } = require('url');

global.location = {
  href: `${pathToFileURL(process.cwd()).href}${sep}`,
};