Closed dgp1130 closed 1 year ago
One idea worth exploring is to move all the meaningful logic to a testable ts_library()
and then simplify the Starlark string literal to be a basic require('my-plugin.config').load()
, that way the Starlark code is simple enough to not require testing and we don't have to worry about a golden test and an update script.
I played with this a little bit, but couldn't get require()
to work successfully. This is working around the linker so module resolution becomes a big issue here. Might need to bundle the plugin configuration script in order to make this work.
We've since moved to Parcel for CSS bundling, so this is no longer an issue.
The PostCSS resolver unfortunately must be implemented as a Starlark string literal based on how it must be loaded.
This means it is entirely untested at the moment. A possible test infrastructure that might be compatible with this:
resolver.ts
which can be compiled and tested normally.resolver.ts
into a single JavaScript source file. Copy that file directly into the Starlark string literal.genrule()
's the resolver Starlark string literal into a real file, and diffs it with the compiled output ofresolver.ts
. Ifresolver.ts
is updated, a test failure will remind developers to copy the output to the Starlark string literal, where it will actually be used from.resolver.ts
and copies the source code into the Starlark string literal. The test can simply notify users to run this update script.This would give a lot more confidence that the resolver actually works as expected, allowing us to test specific edge cases and more confidently change the file going forward.