Add the ability to remap EsModule imports at link time

[Quafadas]

WIP is a rather kind description. A cry for help, perhaps.

This attempts to follow up on VirtusLab/scala-js-cli#47, and close #2698 - i.e. introduce a using directive and / or command line option, to enable the work done in scala-js-cli.

This introduces a failing test, which I can run with;
./mill -i 'integration.test' 'scala.cli.integration.RunTests213.remap imports'

My current headscratcher, is that I don't seem to be able to modify the behaviour of scala-cli itself though. I've liberally put some printlns everywhere - which aren't printed. So I think I'm suffering from some sort of new contributor syndrome.

Would anyone have a hint, on why the intregration test, could be ignoring my attempts to introspect it?

[Gedochao]

One thing this made me realise is that we never bumped scala-js-cli to 1.15.0.1, so I'm doing it in #2738... (I know you're overriding the version in the test, just mentioning, still need to look into your code)

[Gedochao]

My current headscratcher, is that I don't seem to be able to modify the behaviour of scala-cli itself though. I've liberally put some printlns everywhere - which aren't printed. So I think I'm suffering from some sort of new contributor syndrome.

Can you point me at where you're trying to introspect, which prints don't show?

Would anyone have a hint, on why the intregration test, could be ignoring my attempts to introspect it?

a wild guess is that you are printing on stdout, while stdout is being piped in the test...
https://github.com/com-lihaoyi/os-lib/blob/6603eb0e7434c86721806f2c1922452d9d9e49fc/os/src-jvm/ProcessOps.scala#L63-L65
If you want to print the logs when running the integration test (as opposed to when you call a freshly built launcher directly), then you need

os.proc(...).call(cwd = root, stdout = os.Inherit)

as stdout defaults to os.Pipe.
alternatively, you can print on stderr, which defaults to os.Inherit.
No idea if this was the question 😅

[Gedochao]

beyond the above, I'd recommend debugging the launcher directly, instead of printing stuff in the integration tests.

./mill -i integration.test.jvm 'scala.cli.integration.RunTests213.remap imports' --debug
# (...)
# --debug option has been passed. Listening for transport dt_socket at address: 5005

[Quafadas]

Would you have a hint on how to fix this?

I think it's somehow checking the documentation...

[Gedochao]

Would you have a hint on how to fix this?

Yes.
https://github.com/VirtusLab/scala-cli/blob/main/CONTRIBUTING.md#rules-for-a-well-formed-pr
You need to regenerate the reference docs, among other things.

./mill -i generate-reference-doc.run

Also, you may want to rebase on top of main, rather than cherry picking individual commits.

[Quafadas]

@Gedochao @armanbilge This actually ... works ... to my satisfaction.

The happy path works well.

I have a question on error messaging, which is that if I (deliberately) break it, for example by entering a bad file path to my importmap, it produces the error message I'd expect, but it's hidden at the top of the error stack, above scala-cli help. My eyeballs are where the green line is, but the message I need, is where the red line is.

Given that I'm naively throwing an exception, could I be engaging with scala-cli's error handling the wrong way?

[Gedochao]

Given that I'm naively throwing an exception, could I be engaging with scala-cli's error handling the wrong way?

@Quafadas Rather than throwing an exception, you need to return a Left[BuildException].
You'll need to define your own exception type extending BuildException (refer to the existing errors that are returned).

[Quafadas]

• Tighten error messages
• Tests for error conditions
• Tests for happy path
• Manual testing
• Squash
• Docs
• CI green

[Gedochao]

./mill -i __.fix

you need this to satisfy the checks CI job.

[Gedochao]

LGTM