Add support for running JS Spec Tests in browser context.

[jgerigmeyer]

TODO:

• @nex3 confirm overall approach
• fix sourceMap errors
• compile.test.ts
• value/
• function.test.ts
• importer.test.ts
• logger.test.ts

[skip dart-sass]

[jgerigmeyer]

@nex3 This is still WIP, but it'd be good to have your initial review on the overall approach here, and how the tests and setup files are re-arranged a bit.

[jgerigmeyer]

Before merging, this should be updated:

Suggested change

	# TODO update this to use https://github.com/sass/dart-sass.git
	git clone https://github.com/oddbird/dart-sass.git ../dart-sass --depth 1 --branch browser
	git clone https://github.com/sass/dart-sass.git ../dart-sass --depth 1

[nex3]

Approach looks good to me!

[jgerigmeyer]

@nex3 Looking at the remainder of the JS API spec tests, I'd like your feedback on which ones we should be supporting in a browser context. Here are my initial thoughts/questions:

• legacy/ -- I assume we can skip these
• value/ -- Do we want to run these? If so, we'll need to expose the various types (e.g. SassArgumentList, SassList, sassNull, etc) for the browser build.
• function.test.ts -- Similar to value/; if we want to run these, we'll need to expose CustomFunction, SassString, and sassNull.
• importer.test.ts -- Do we want to run (some of) these? I assume we'd skip the ones that rely on FS access (via sandbox()), but it's possible we could run some of the tests.
• logger.test.ts -- I assume we want some logging/debug support in the browser build, but given the differences between console and stdio, it might make sense to write a subset of logging tests specifically for the browser context, and not copy any of these over to run in both contexts?

[nex3]

@nex3 Looking at the remainder of the JS API spec tests, I'd like your feedback on which ones we should be supporting in a browser context. Here are my initial thoughts/questions:

• legacy/ -- I assume we can skip these

Yep, totally ignore these.

• value/ -- Do we want to run these? If so, we'll need to expose the various types (e.g. SassArgumentList, SassList, sassNull, etc) for the browser build.
• function.test.ts -- Similar to value/; if we want to run these, we'll need to expose CustomFunction, SassString, and sassNull.

We should definitely support these. We want people to be able to use custom functions on the browser.

• importer.test.ts -- Do we want to run (some of) these? I assume we'd skip the ones that rely on FS access (via sandbox()), but it's possible we could run some of the tests.

Yeah, I think we should separate out the ones that test importer/filesystem interactions into a separate file and run the rest on the browser.

• logger.test.ts -- I assume we want some logging/debug support in the browser build, but given the differences between console and stdio, it might make sense to right a subset of logging tests specifically for the browser context, and not copy any of these over to run in both contexts?

We could potentially abstract captureStdio() into a function that captures stdio on Node and console.log() on the browser. If that's infeasible, then maybe we should have three test files under a logger/ directory: Node-specific, browser-specific, and platform-agnostic.

[jgerigmeyer]

@nex3 @jerivas I think this is ready for another (close to final?) round of review!

[jerivas]

LGTM!

[jgerigmeyer]

Dart Sass running as browser JS

[jgerigmeyer]

@nex3 Full transparency, I just realized yesterday that Karma is officially deprecated as of a few weeks ago. 🤦

I think there's potential for switching to either Web Test Runner or jasmine-browser-runner, but after trying them out a bit today I ran out of steam. I'd be happy to chat more about pros/cons of those two options, but I think I'd recommend that this is a good start, and we can consider a switch to Web Test Runner sooner or later.