Skip to content

Conversation

sjrd
Copy link
Member

@sjrd sjrd commented Mar 18, 2017

No description provided.

@sjrd sjrd requested a review from gzm0 March 18, 2017 17:27
@sjrd
Copy link
Member Author

sjrd commented Mar 18, 2017

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 @JSGlobal? I think at some point you showed me a repo with an example, but I can't find it anymore.

@sjrd
Copy link
Member Author

sjrd commented Mar 19, 2017

Documentation done, and I also updated the tutorial. The updated tutorial code/history is available in the dev branch.

@sjrd
Copy link
Member Author

sjrd commented Mar 20, 2017

Artifacts are on Maven, CLIs are published, and Scaladocs are set up.

@olafurpg
Copy link
Contributor

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 sbt scalafix will do the rest. I decided to merge the rewrite into the scalafix repo just because it serves as a nice test. However, you can copy this file to some scala-js repo and users could run that rewrite by putting into .scalafix.conf

rewrites = ["https://rawgithub...."] 

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!

@sjrd
Copy link
Member Author

sjrd commented Mar 21, 2017

@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 :)

Copy link
Contributor

@gzm0 gzm0 left a 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.
Copy link
Contributor

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.

Copy link
Member Author

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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as opposed to @JSName

Copy link
Member Author

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 %}
Copy link
Contributor

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.

Copy link
Member Author

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() in js.JSApp for compatibility
  • deprecate JSApp
Copy link
Contributor

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`.
Copy link
Contributor

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).

Copy link
Member Author

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.
Copy link
Contributor

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.
Copy link
Contributor

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

Copy link
Member Author

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.

@sjrd
Copy link
Member Author

sjrd commented Mar 21, 2017

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 %}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SG

@sjrd sjrd merged commit 9945213 into scala-js:master Mar 21, 2017
@sjrd sjrd deleted the scalajs-0.6.15 branch March 21, 2017 13:35
@gzm0
Copy link
Contributor

gzm0 commented Mar 21, 2017

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants