We've been wanting to do that for a while, actually. So-called "linker plugins", similar to scalac plugins. We'll probably work on this sometime post-1.0.0, though, based on an even simpler Tools API.

What would help correctly designing such an interface would be to have concrete use cases, though. So if you have some, feel free to post them as comments herein.

I have a concrete use case where I manipulate IR before packing it
https://github.com/akka-js/akka.js/blob/master/project/IrPatcherPlugin.scala

basically what I do is to have a separate subproject that implements patches to be applied on the master IR.
This works, but actually has got a number of limitations...

@andreaTP That use case is actually quite different from what I associate this issue to. In your case you patch IR at compile-time, before putting it in .jars. This does not interact with the linker in any way, so it doesn't really fit in a "linker plugin". IMO the way this use case is currently implemented is pretty much already as good as it gets. You could of course make it a linker plugin, but then you'd have to impose that linker plugin to all the users of your library, whereas right now it only needs to be applied in your own build, without users noticing anything.

Linker plugins would transform the IR at link-time, when we have the IR of the whole program. Probably before linking (raw IR) or after linking but before the optimizer kicks in (linked IR).

Allowing custom transformations after the optimizer is too dangerous currently, because the validity of what the optimizer outputs is only specified by "it goes through the Emitter somehow, with appropriate semantics". Everything before the optimizer is much better specified.

I do not read anywhere "linker-plugin" in the original proposal,
it talks about:

custom rewrite and optimisation rules/transformations

I agree that my transformations aren't checked, and that's why I'm proposing it as a use-case.
Anyhow I really see a point in applying trasformations before putting in jar because it affect only the original codebase and doesn't force users to be aware of dirty tricks.

I'm sorry. I forget what I had in mind when I raised this. (I've been sick in bed for 5 days; fever stole my ideas, let's blame that!)

All I can think of now is rewriting Option to be js.UndefOr which I admit, doesn't seem likely.

Here's a cool abstract idea: I'd like to be able to define my own optimisations or AST customisation before writing JS. There are a number of optimisations that apply to pure code that you can't make universally in Scala because of a lack of guarantee, or analysis of purity, which means ambiguous semantics always need be preserved. It might be a cool idea to grow a library of optimisations safe for pure code and say "these work great so long as you follow these common FP rules, they aren't for everyone".

That would be hard to write, because you'll have a hard time deciding in which part of the codebase you can apply your optimisations. For example the implementation of the collections is definitely not pure, so you would have to avoid rewriting those.

I think this would be mostly useful for domain-specific optimizations. If your library has some properties that allows optimizing certain method calls, you could use such a plugin to do so. But my hunch is that you would need to make sure that these optimizations are always correct, the only requirement being that your library semantics themselves are what you think they are.