You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: various fixes to extension dev/test flow (#5885)
* fix: pass pluginsEnv to integration build hooks build step
For context: `@netlify/build` automatically builds integrations when
`context` is set to `dev`. This PR 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.
```ts
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.
* fix: resolve integration dev path relative to buildDir
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 don't think this makes any sense, honestly. 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
Composable Platform has.
* fix: return integration build plugin path in development
Currently, when running a build in `context=dev` mode for a site that
installs an extension never actually installs the extension's build
plugin, if it has one.
That's because the integration package resolver doesn't return the path
to the built package (tarball), so build never picks it up as a plugin.
This changeset fixes that issue.
* refactor: print stack on failure to build integration in dev mode
* style: run prettier
* fix: remove duplicative integration install step
In 0cfe6d8 I introduced a duplicative integration install step when
`context=dev`, not realizing that we have a special case for resolving
integrations in dev mode:
https://github.com/netlify/build/blob/main/packages/build/src/plugins/resolve.js#L189-L195
Returning the tarball location meant we were installing the
integration's packed tarball and then also installing from the pre-pack
build directory. This changeset removes that duplication.
It's... weird that we don't just return the location of a packed npm
package (tarball) and instead have a special case that points at the
pre-pack build artifact directory. This sort of special-cased action at
a distance makes it super hard to understand how this works. I'm going
to circle back on de-confusing this sometime this quarter when I make
the extension build artifact path configurable, which will solve a lot
of testing pain points we currently have.
The failing test I also fix in this changeset was never realistic and
didn't exercise some of the code paths it was supposed to put under
test, so I've updated that test fixture to be realistic.
0 commit comments