com-lihaoyi
Feedback on javascriptlib
I've been experimenting with the javascriptlib to support building a JavaScript/TypeScript application and have some feedback I wanted to offer.
TypeScriptModule
The TypeScriptModule provides a good means of building code that uses TypeScript with support for doing this in a manner that works with mill's sandboxing capabilities. The sandboxing mill provides doesn't work naturally with how JavaScript tools work, so the support provided by this module is invaluable. I have however noticed that the TypeScriptModule is not as extension friendly as one might hope.
Custom package.json fields
The TypeScriptModule offers the packageJson task and TypeScriptModule.PackageJson types which make it possible to configure package.json in your mill build file. While this is convenient, various tools in the JavaScript ecosystem often require adding custom (non-standard) package.json fields and users need a simple way to add these custom fields.
I'd suggest extending the PackageJson type to support adding custom fields in addition to the helper fields that are present for the more common fields.
Customizing Compiling & Bundling
It seems the ReactScriptsModule is intended to offer an approach for building React apps using the react-scripts tool. This involves plugging in a different approach to compilation than the base one provided by TypeScriptModule. Similar to this I have had a need to use Vite as the JavaScript build tool that is used for compiling/bundling my application. But I have also worked on projects that use parcel, webpack, or even bun to do this packaging. The ReactScriptsModule that currently exists actually loses some of the sandboxing benefits and package.json management that the base TypeScriptModule provides because it totally overrides the compile task and is unable to use the base compile task since it adds additional settings to package.json and chooses to build with a different tool.
It seems like we should support a way to easily replace the tool used for typechecking, compile/build, test, and bundle without losing the sandboxing benefits provided by TypeScriptModule.
Some of these issues can be solved by changing the access modifier on methods provided by the TypeScriptModule type, but other parts of this require a redesign of the approach of the build task to keep in mind the every evolving nature of the JavaScript ecosystem and its grab bag of tools which is less consistent than JVM languages for example.
I'm interested in thoughts around how to best approach these issues and the goal of making it easy to swap in tools and perhaps think of compile, bundle, test, and typecheck as stages in a pipeline that should have pluggable "steps".
I think making the various "standard" build steps in javascriptlib pluggable. Seems reasonable given the wide variety of options that the JS ecosystem has for performing each step in a project's build pipelines. Given the experimental nature of javascriptlib, making more things public to allow for experimentation sounds great
Custom package.json fields
uPickle now supports the @flatten annotation (https://com-lihaoyi.github.io/upickle/#@flatten), which allows you to povide/receive extra key-value pairs that are not part of the case class's fields. We can keep the existing case class PackageJson data type and add a @flatten extra: Map[String, ujson.Value] which would allow the user to provide arbirtrary extra key-value pairs to be included in the generated JSON structure
Custom package.json fields
uPickle now supports the
@flattenannotation (https://com-lihaoyi.github.io/upickle/#@flatten), which allows you to povide/receive extra key-value pairs that are not part of thecase class's fields. We can keep the existingcase class PackageJsondata type and add a@flatten extra: Map[String, ujson.Value]which would allow the user to provide arbirtrary extra key-value pairs to be included in the generated JSON structure
This requires upickle 4.1.0, I assume that takes backporting to 0.12.x off the table because of binary compatibility reasons, right?