Prevent installation of optional peer dependencies when packaging externals about serverless-esbuild HOT 13 CLOSED

I am not sure yet, but as of now I think you are right, we should probably just implement plugins (I wanted to make a PR this week but have been delayed) and leave this as a workaround. This is a true edge-case, I think there is a questionable design from the pg library. But I can only agree with you when you note that it's probably outside of the scope of serverless-esbuild.

from serverless-esbuild.

@olup I agree, optional peers must be skipped, but I don't think we should manage it with our packaging logic, it should be handled by esbuild, otherwise it would be an unexpected side effect.
See #97 I think this is related somehow, we just need to implement plugin support to handle this case.
Basically it's how all the world does with pg-native:

new IgnorePlugin({
      resourceRegExp: /^pg-native$/,
})

to be honest I do not really like this dirty solution, so maybe it really makes sense to change the world here and incapsulate in our packaging logic. what do you think?

from serverless-esbuild.

Agreed, let's prioritise plugin support and if it solves the edge case then we are good

from serverless-esbuild.

I'll close it then.

from serverless-esbuild.

I'm also running into this problem :(

For me particularly, JSDom has an optional peer dependency of canvas which is causing all sorts of grief.

My question is though, how is canvas getting downloaded and installed in this process? It's not actually downloaded anywhere else, so npm must be getting called at some point to grab it during watch?

from serverless-esbuild.

Hello ! Can I ask how you use JSDom in your code? Specifically, is it something you bundle as external?

from serverless-esbuild.

Yup, marked as external in serverless.yml

  esbuild:
    bundle: true
    minify: false
    target: es2019
    format: cjs
    external:
      - aws-lambda
      - got
      - keyv
      - jsdom

And merely having jsdom as a dependency causes canvas to be pulled into node_modules in the build (it's an optional peer dependency of jsdom, if it's pulled in it changes the behavior and we do not need it). I even fully removed jsdom from code, and it's only listed in dependencies in package.json.

Although if never importing jsdom in code doesn't create the cascade of problems bringing in canvas has, but it's still in the .ebuild/.build/node_modules folder for whatever reason

from serverless-esbuild.

Yes, that's the thing, check : #104

External are pulled with their optionals peer dependencies as of now. Plugins support will provide a workaround. But we might do something more backed in.

from serverless-esbuild.

We are on #104 :)

Yeah I had a peek of the code and it does just pull down all peers without any condition. Simply removing that chunk did resolve it for me.... What was the rationale of grabbing all the peers like that? Seems like it'll likely cause more issues than solve

from serverless-esbuild.

Lol sorry, answering too early after wake up. Yes, as you read, we are thinking of some ways to fine tune this, I am not sure myself why this was added in the first place.

By the way, plugin support is here so if you need a quick fix you can use that to exclude the peer dep.

from serverless-esbuild.

@floydspace thinking about it more, it might actually be our responsibility to not install optional peer deps in the case of externals as we are the one installing them in the first place, don't you think ?

@mattisdada it's expected our our packaging to include the peer dependencies of the external modules, however I agree optionals could probably be skipped, and let user include them if needed.

from serverless-esbuild.

@olup you might be right, if we choose not to bundle a certain dep (with optional peers), our packager comes to the game which has to do the job right

from serverless-esbuild.

@mattisdada what about #113 ? Is that solving your problem ?

from serverless-esbuild.