Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Esbuild should support plugins #15021

Closed
1 task done
ndcunningham opened this issue Feb 15, 2023 · 2 comments · Fixed by #16092
Closed
1 task done

Esbuild should support plugins #15021

ndcunningham opened this issue Feb 15, 2023 · 2 comments · Fixed by #16092
Labels
outdated scope: bundlers Issues related to webpack, rollup type: feature

Comments

@ndcunningham
Copy link
Contributor

Description

Nx plugins primarily get target (build/lint/test) configurations from a json file project.json.
Which works in the majority of scenarios.

However, the esbuild plugins API allows users to provide a setup function which is passed to the build API.
https://esbuild.github.io/plugins/#finding-plugins

As at our current state Nx 15.7.0 we do not fully support this approach.

Motivation

Initially, this came out of an issue: #14823
PR: to remove plugin in favour of doing it as a feature: #14997

Suggested Implementation

The prospective implementation would be similar to what @jaysoo highlighted.

// esbuild.config.ts
export default {
  //...
  plugins: [require('foo-plugin')]
}

Additionally, should you provide configurations through project.json and esbuild.config.ts we would have a priority merging
For example priority would be

  1. esbuild.config.ts
  2. project.json configuration
  3. Nx internal configuration
  4. External configuration

Alternate Implementations

Also support .js files

// esbuild.config.js
module.exports = {
  // ...
  plugins: [require('foo-plugin')]
};
@jaysoo
Copy link
Member

jaysoo commented Feb 15, 2023

I think 2-4 are essentially the same case because passing via CLI will override both the Nx and project configurations. And from the executor's POV, it's all treated the same way.

The main prioritization should be Nx > esbuild.config.js.

Here's an example use case:

  1. User defines export default { bundle: false } in their esbuild.config.js
  2. User runs nx build <app> --bundle=true
  3. Nx will run with bundle: true since it is passed in from CLI. Otherwise, there is no way to override esbuild.config.js.

This is the same thing we do for Vite.

One more consideration is how we can make it type-safe. Vite and other tools export an identity function defineConfig that type-checks that the config is matching what's expected.

So we can do:

// esbuild.config.ts
import { defineConfig } from '@nrwl/esbuild';

export default defineConfig({
  plugins: [...]
});

If it's an JS (or user doesn't care about type-checks) they could just do:

module.exports = {
  plugins: [...]
};

@github-actions
Copy link

github-actions bot commented May 5, 2023

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated scope: bundlers Issues related to webpack, rollup type: feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants