- Notifications
You must be signed in to change notification settings - Fork 147
Announcing Scala.js 0.6.15. #349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Here are already the release notes. I still need to update the docs. @olafurpg What should I tell in the release notes to people who want to use scalafix to migrate to |
Documentation done, and I also updated the tutorial. The updated tutorial code/history is available in the |
Artifacts are on Maven, CLIs are published, and Scaladocs are set up. |
I just released scalafix 0.3.2 which contains necessary changes to run the DemandJSGlobal rewrite. The necessary diff for users to run the rewrite is --- /dev/null +++ b/.scalafix.conf @@ -0,0 +1,3 @@ +rewrites = [DemandJSGlobal] +imports.organize = false (optional) +imports.removeUnused = false (optional) diff --git a/project/build.properties b/project/build.properties index 817bc38..27e88aa 100644 --- a/project/build.properties +++ b/project/build.properties @@ -1 +1 @@ -sbt.version=0.13.9 +sbt.version=0.13.13 diff --git a/project/plugins.sbt b/project/plugins.sbt new file mode 100644 index 0000000..442d537 --- /dev/null +++ b/project/plugins.sbt @@ -0,0 +1,2 @@ +addSbtPlugin("ch.epfl.scala" % "sbt-scalafix" % "0.3.2") Then
More examples on custom rewrites is here: https://scalacenter.github.io/scalafix/#Customrewrites For troubleshooting, refer users to https://scalacenter.github.io/scalafix/#FAQ/Troubleshooting Congrats on the release! |
@olafurpg Awesome! I've tested it with scalajs-dom, and it works beautifully! See the PR scala-js/scala-js-dom#277 I'll integrate the setup instructions in the release notes, and announce in the afternoon :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah crap... Didn't send my comments from the weekend :(
| ||
This release was focused on preparations for Scala.js 1.0.0. | ||
In particular, it should contain the last deprecations for things that are being replaced by better alternatives. | ||
If your code and build compile without warnings with 0.6.15, it should continue to work unchanged in 1.0.0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would be cautious to claim this: For example, once #2797 gets resolved, we really should get rid of commonJSName
in the jsDependencies
system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The jsDependencies
will move to a separate sbt plugin where we can afford to keep crappy things forever ^^
class Bar extends js.Object | ||
{% endhighlight %} | ||
| ||
This is now deprecated: `@js.native` objects and classes should now explicitly use the annotation `@JSGlobal` (as opposed to `@JSImport`) as follows: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as opposed to @JSName
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum ... I really meant JSImport
, in the sense that either you have @JSGlobal
or @JSImport
. I guess the parentheses are confusing. I'll remove that.
object Foo extends js.JSApp { | ||
def main(): Unit = { ... } | ||
} | ||
{% endhighlight %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Humm... This is not 100% true. JSApp
relies on @JSExportDescendentObjects
. So the change is only safe in combination with using the new module initializer feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JSApp
still has @JSExportDescendentObjects
, so the change is safe regardless in 0.6.x. We'll have to decide what to do with JSApp
with 1.0.0, though, but that's another issue. My current idea is to:
- re-introduce
main(Array[String])
detection in sbt - use a
ModuleInitializer
that can call those methods - add
def main(args: Array[String]): Unit = main()
injs.JSApp
for compatibility - deprecate
JSApp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SG
#### Migration tips | ||
| ||
**Are you maintaining a testing framework?** | ||
If you use our `TestUtils.newInstance` and/or `TestUtils.loadModule` methods to perform reflective instantiation of `@JSExportDescendent...` things, all you need to do replace `@JSExportDescendentClasses` and/or `@JSExportDescendentObjects` by `@scala.scalajs.reflect.annotation.EnableReflectiveInstantion`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should also say that newInstance
needs to switch to the new overload (the one that takes the argument types).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, indeed!
The new API is more reliable and powerful, especially for classes inside objects, as well as classes with overloaded constructors. | ||
| ||
Reflective instantiation is still not enabled by default for all classes in the world (as that would completely inhibit dead code elimination). | ||
Used on a trait, class or object, the annotation `@EnableReflectiveInstantion` enables reflective for all the non-abstract classes and all the objects inheriting from the annotated entity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
enables reflective instantiation
### Deprecated: Run without `scalaJSUseMainModuleInitializer` | ||
| ||
It is still possible to `run` a Scala.js application that does not have `scalaJSUseMainModuleInitializer := true`. | ||
However, this is not recommended anymore. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to remove this? I realize this is a necessary consequence of getting rid of @JSExportDescendentObjects
but it seems like a useful feature :S
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it's actually useful.
I'm not certain we'll not have to reinstate that feature in some way, but for now I figured it doesn't hurt to tell people they shouldn't use it. If we don't, we'll never get any complaints, and we won't know that there are use cases for the feature.
Updated. @gzm0 I have notably been more careful with the "your code will keep working" sentence ;) |
object Foo extends js.JSApp { | ||
def main(): Unit = { ... } | ||
} | ||
{% endhighlight %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SG
🎉 |
No description provided.