search

untyped / sbt-plugins

SBT plugins for Javascript, Coffeescript, LESS, SASS, and Mustache compilation
73 stars 23 forks source link

Rename sbt-js to sbt-coffeescript #40

Closed mdedetrich closed 11 years ago

mdedetrich commented 11 years ago

This should be done sooner than later, as the sbt-js subproject name is confusing and doesn't match the naming of the other sbt- subprojects (i.e. sbt-mustache and sbt-less, we don't call these subprojects sbt-html and sbt-css)

Doing the rename means we consistent naming scheme, i.e. if we want to add typescript the subproject name would be sbt-typescript

I would be willing to make a pull request to implement this if there are no qualms about this, note that it is obviously a breaking change should it happen ;). Note sure if we should do it for 0.6 or for a later revision

davegurnell commented 11 years ago

I see the discrepancy in naming, but I disagree that sbt-js is misnamed. I also don't think it's worth renaming the plugin - there's enough confusion in SBT/Maven/Ivy-space as it is.

IMO sbt-js is as much about plain Javascript as it is about Coffeescript. The plugin does other things than simply support Coffeescript (minification, dependency management, etc).

I don't know much about Typescript and I haven't considered developing an SBT plugin for it. If I was adding it to this project, I don't know whether the best thing would be to add a separate plugin or add it to sbt-js to allow multi-file-format builds. What are your thoughts on this?

davegurnell commented 11 years ago

I'm going to close this ticket for now pending further discussion.

mdedetrich commented 11 years ago

I see what you mean, I think it would be worth it to split up sbt-js with sbt-coffeescript and sbt-js and have sbt-coffeescript depend on sbt-js (and any other language -> js compilter also depend on sbt-js)

There is also a scala-js compiler out there that is being developed (https://github.com/lampepfl/scala-js) which we may want to support when it becomes production ready. We can also put in common resources in the split sbt-js, for example a lot of language -> javascript compilers will use rhino (or maybe JRuby), which we wan't to share as a common dependency inside sbt-js.

The reason I am against clumping all of the javascript languages into sbt-js (apart from the not making sense naming scheme wise) is that most people only tend to use one language, and if they do happen to use multiple languages they may want to compile it in different sections/areas of the code (might happen when you have one massive project that uses code from somewhere else). This will also allow sandboxing and managing your language -> javascript sources manually

I don't see much value in sbt-js auto picking up language -> js sources, if you are writing typescript files (*.ts) then you will know you are using typescript and hence you would import a sbt-typescript

Also a similar thing can be done in regards to CSS processors when we want to support stuff like stylus (http://learnboost.github.io/stylus/)