search

vmunier / scalajs-scripts

Twirl templates to link Scala.js output scripts into a HTML page.
Apache License 2.0
60 stars 11 forks source link

Support for sbt-web-scalajs 1.2.0? #48

Closed ianknowles closed 3 years ago

ianknowles commented 3 years ago

With the changes in 1.2.0, the asset locations have changed. So the generated templates are no longer pointing to output scripts. The example project was updated to remove scalajs-scripts. Is this temporary or is this library now deprecated? I prefer the current implementation with a helper function in twirl but I can see that maybe its not great to have to maintain a seperate library just for it, when it maybe doesn't have access to the plugin js stages.

Rather than the new template (which I'm not keen on adding common boilerplate to my source tree and it could end up confused if multiple stages exist) it should be possible for sbt-web-scalajs to generate an object that contains the scalaJSStage for import into twirl. sbt-buildinfo does similar with more general sbt build settings, hello.BuildInfo.name in their example would let you access the sbt project name in play/twirl source. I don't know enough about sbt plugins at the moment to send a pull request for it anytime soon, sorry.

vmunier commented 3 years ago

Hi,

Yes, scalajs-scripts is deprecated when using sbt-web-scalajs v1.2.0. I have just updated the README.md.

scalajs-scripts was convenient to remove some boilerplate code and include the launcher, jsdeps and the fastopt/opt files simultaneously. There's no launcher file anymore, and I suspect scalajs-bundler is used in place of jsdependencies now, so no more jsdeps file. When there's only the fastopt/opt file to include, the benefit of using a library like scalajs-scripts is limited.

Scala.js can also emit JavaScript modules instead of a top-level script. When using modules, there could be files with different names to include, and scalajs-scripts does not provide any templates in this case.

That's why I think it makes more sense to let the user create their own templates, using Twirl or any other template library, which correspond to their needs.

We could modify the existing scripts to point to the new location, i.e. point to client-fastopt/main.js instead of client-fastopt.js. However, as said above, it would only be helpful when using top-level scripts.

As for generating a Scala object that contains the scalaJSStage, not sure that's necessary and I don't think it should be sbt-web-scalajs responsibility to generate such object.

I am happy to let this issue open to see if people have suggestions on how scalajs-scripts could still be useful.

ianknowles commented 3 years ago

Scala.js can also emit JavaScript modules instead of a top-level script. When using modules, there could be files with different names to include, and scalajs-scripts does not provide any templates in this case.

I don't think this makes the case for every user of sbt-web-scalajs to create their own twirl boilerplate, as every user of the library would have to do this and it involves inferring the output directory for different stages instead of looking it up, it belongs in a library/plugin somewhere I think. I don't know enough about the scala.js plugin at the moment to understand the responsibility/source of truth for the config of the output structure, so no idea at the moment of the best place to solve this.

vmunier commented 3 years ago

I have reintroduced scalajs-scripts. v1.2.0 has just been published, which supports sbt-web-scalajs v1.2.0, i.e. it includes the <project>-<fastopt|opt>/main.js file.