These are chat archives for sbt/sbt

13th
Sep 2016
BennyHill
@BennyHill
Sep 13 2016 15:27
Hi! If I am creating a plugin - e.g. sbt-scoverage - that can be used for either/or a JVM/scala.js project, I don't want users of the plugin to pull in scala.js if they only have a JVM project. For libraries, it's easy - just use %% for a JVM only project or %%% for a mixed/JS only project. Does a similar framework exist for sbt plugins, too?
A related question would be disabling plugins for sjs, too, eg tkawachi/sbt-doctest#69
I can imagine a bunch of ways to do this "manually", I'm more curious if there is an "official" way
Dale Wijnand
@dwijnand
Sep 13 2016 16:32
I don't understand the connection between sbt-scoverage and scala.js.
BennyHill
@BennyHill
Sep 13 2016 16:40
The unreleased version of sbt-scoverage has scala.js support
Dale Wijnand
@dwijnand
Sep 13 2016 20:14
@BennyHill the way %%% works is it's grabing different plugins. So I guess a naive approach you could take it publishing a sbt-scoverage and a sbt-scoverage-js (or similar)
BennyHill
@BennyHill
Sep 13 2016 20:14
Sure, make sense
Dale Wijnand
@dwijnand
Sep 13 2016 20:14
But besides that, I would wait for it to be a problem :)
BennyHill
@BennyHill
Sep 13 2016 20:15
it is :)
scoverage/sbt-scoverage#182
so in that PR I just whacked in sjs ;)
Perry
@pfn
Sep 13 2016 20:17
I don't see why sjs matters for a plugin...
'cos it's a plugin that loads a lib that has a jvm and sjs version
Dale Wijnand
@dwijnand
Sep 13 2016 20:18
Yeah I'm not following at all what's going on either.
and the later has two components - a compiler plugin and a cross lib to write output to the fs
I think having two plugins as @dwijnand suggests ^^ is likely the nicest soln for now
Dale Wijnand
@dwijnand
Sep 13 2016 20:21
:+1:
BennyHill
@BennyHill
Sep 13 2016 20:22
yep :+1: nn:)
Perry
@pfn
Sep 13 2016 20:34
yeah, but the sjs version won't be loaded unless. you have sjs in your project
BennyHill
@BennyHill
Sep 13 2016 20:40
correct, but a jvm only project that uses the sbt-scoverageplugin will see the scala-js plugin downloaded
as @dwijnand hints, that may not be a problem but....
certainly for now I'm going for the easy route ;)
Dale Wijnand
@dwijnand
Sep 13 2016 20:41
I would start with that.
BennyHill
@BennyHill
Sep 13 2016 20:41
:+1:
Dale Wijnand
@dwijnand
Sep 13 2016 20:43
You could also do something like libraryDependencies.value.exists(_.name == "scalajs-library")
BennyHill
@BennyHill
Sep 13 2016 20:45
yep, plus removing the %%% and hand crafting the full sjs name
so phase 1 = easy, just get it working
phase 2 = some more work to refine it
Perry
@pfn
Sep 13 2016 20:52
the sbt scoverage plugin depends on scala js plugin?
BennyHill
@BennyHill
Sep 13 2016 20:52
A simple sbt-platform plugin could add if (Platform.isJS) Platform.qualify(libname) where qualify adds the _sjs0.6.12 bits. Same for llvm,etc. Saves this - https://github.com/scoverage/sbt-scoverage/pull/166/files#diff-627f9fd5c400939149d75695caad1988R68

the sbt scoverage plugin depends on scala js plugin

Yeah - conditionally though. Or rather, optionally

Perry
@pfn
Sep 13 2016 20:53
but sbt plugins. don't. have conditional. dependencies
nor. does ivy/pom
it does or it doesn't
BennyHill
@BennyHill
Sep 13 2016 20:54
Don't get me wrong, I've no problem getting this working, I just see something general here

but sbt plugins. don't. have conditional. dependencies

Exactly :)

Perry
@pfn
Sep 13 2016 21:00
I see. no. dependency on sjs in that repo
I still don't understand how there's a problem here