search

ptrdom / scalajs-vite

Bundles Scala.js projects and their npm dependencies with Vite
MIT License
14 stars 1 forks source link

Customization of vite configuration #40

Closed johnhungerford closed 6 months ago

johnhungerford commented 9 months ago

It is important to be able to customize build configurations. scalajs-bundler had the ability to specify custom webpack configurations. In sbt-vite I used a similar but more flexible (but also more complicated) approach of specifying a collection Seq[sbt.File] of custom configuration that would be merged in order. This allows sharing configurations between projects but then overriding specific settings per-project.

I've also found it useful to be able to update the environment and the arguments for the various commands. For instance, it's necessary to include NODE_ENV=development when bundling react projects to ensure that it's bundled with a development react build (this is necessary for tests to work, for instance). I also need (for the time being) to use --legacy-peer-deps when running npm install.

ptrdom commented 9 months ago

I wonder if for all of this it would be enough to do the following:

  1. Allow scoping PackageManager and ViteRunner values per sbt built-in scopes. Would need to have specific cases in mind to make sure that is good enough.
  2. Within PackageManager and ViteRunner allow specifying not only command as String, but arguments as List[String] also.
johnhungerford commented 9 months ago

I think that makes sense, IIUC, and that's how I've done it in sbt-jsbundler (and also here).

In other words, customize all configuration by via bundler and package-manager construction rather than adding a bunch of new settings. I prefer this approach for sure, although I don't see it used very often in plugins.

ptrdom commented 9 months ago

2. Within PackageManager and ViteRunner allow specifying not only command as String, but arguments as List[String] also.

This part is also not truly necessary, because custom implementations of PackageManager and ViteRunner, that pass additional arguments to commands, can be provided with the current plugin implementation. So it seems that scoping is the only critical part.

ptrdom commented 6 months ago

I wonder if for all of this it would be enough to do the following:

  1. Allow scoping PackageManager and ViteRunner values per sbt built-in scopes. Would need to have specific cases in mind to make sure that is good enough.
  2. Within PackageManager and ViteRunner allow specifying not only command as String, but arguments as List[String] also.

Closing because both parts are actually already implemented.