fix: various fixes to extension dev/test flow

[ndhoule]

Summary

This changeset fixes several issues that come up when you use @netlify/build programmatically to test integrations extensions' build hooks. A few of these issues can be worked around by running @netlify/build in a subprocess, but some of these make it difficult or impossible to write tests for extension build hooks at all.

This PR is a collection of a few small, related fixes; I added an explanatory commit message for each small commit, collected below so they stick around after the squash. (Happy to break this into three PRs upon request.)

254f154

For context: @netlify/build automatically builds integrations when context is set to dev. This changeset targets that functionality.

Without this change, buildSite's programmatic interface doesn't pass programatically defined env variables into the task that builds integrations extensions' build hooks.

import buildSite from "@netlify/build";

await buildSite({
  env: {
    // This is passed to the build plugin when it's executed, but is not
    // passed to the task that builds the plugin.
    SOME_ENV_VAR: "1",
  },
});

I don't know if pluginsEnv or childEnv is the more appropriate value to pass here, but pluginsEnv seems more consistent with how build treats integrations as plugins, so I chose to use it.

Two total digressions I thought of while writing this:

• We should probably be passing extendEnv: false to the execa invocation that builds the integration, but I'm not sure if that would break something at this point, so I'm leaving it as is for now.
• I sort of hate that @netlify/build builds the integration automatically. It's challenging to use it in tests: every test rebuilds the integration (which is expensive) and you have to make sure that no two tests that auto-build the integration build it concurrently, otherwise you might end up with test flakes when one test writes to the built tarball while another test is installing from it. I don't yet know what the best way to solve this problem is, so I'm punting on solving it for now.

3e3234c

Currently, programmatic executions of buildSite resolve a development integration's path (specified via netlify.toml#integrations[].dev.path) relative to the current working directory.

I find this (undocumented) behavior unintuitive; if I specify a relative path in a netlify.toml I would expect it to be resolved relative to the netlify.toml.

This is technically a breaking change, but in practice I really doubt any users are testing extension build hooks, it's unlikely to break anything for the platform team (maybe a few tests, but we can update the paths in those tests if it does).

I'm tempted to remove testOpts.cwd here because I can't find anywhere that we use it internally and it's unintuitive, too, but I'm leaving it in for now as an easy escape hatch in case this change breaks any tests in the SDK.

3f86cd1 / dbd2472

These two commits mainly fix an extension-specific test fixture that was not realistic and broke when I made some of these changes. 9d90cb7 made the fixture realistic and reverted 8972e84, which I realized wasn't actually necessary. (For more context, see the commit message for dbd2472.)

[github-actions]

This pull request adds or modifies JavaScript (.js, .cjs, .mjs) files.
Consider converting them to TypeScript.

[ndhoule]

Still need to fix these tests.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[serhalp]

😱 @ndhoule quick fix and maybe find the missing eslint rule to enable? 😬

[ndhoule]

Oof, sorry about this! I'll fix it this morning and add an ESLint rule.