typelevel / typelevel/sbt-typelevel
JS projects activated by `enable(ScalaJSBundlerPlugin)` are put in `rootJVM`
Nobody has claimed this yet.
- Dominant language
- Scala
- Stars
- 185
- Forks
- 62
- PR merge metrics
- No merged PRs in 30d
Description
Thanks to @bblfish for identifying this problem.
Unless a project explicitly enables the ScalaJSPlugin then it cannot be identified as a Scala.js project. Even though ScalaJSBundlerPlugin requires ScalaJSPlugin that apparently is not sufficient.
The problem is the detection logic here.
https://github.com/typelevel/sbt-typelevel/blob/fb3c7d871e88c3eeef8bc73b57f9f90559c8386a/ci/src/main/scala/org/typelevel/sbt/CrossRootProject.scala#L72
The easy fix is to special-case this, but I don't want to special-case every plugin that requires the ScalaJSPlugin. It would be nice to find a more robust way to do this detection stuff.
Meanwhile, the workaround is easy and harmless albeit annoying. The bug itself is fairly harmless too AFAICT, your tests etc. still run in CI, just as part of the rootJVM job.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at ci/src/main/scala/org/typelevel/sbt/CrossRootProject.scala around line 72, where Scala.js projects are detected. Investigate how project plugins are identified when ScalaJSBundlerPlugin enables Scala.js indirectly. Done means those projects are classified separately from rootJVM without adding a special case for each requiring plugin, while CI tests continue to run.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- build-system, ci-cd
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100