-
Notifications
You must be signed in to change notification settings - Fork 3
Import the PhantomJS env from the Scala.js core repository. #1
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
- Fix scala-js/scala-js#442: Add Phantom.js environment - Add a setting whether a project requires the DOM
…s#958) This commit removes support for `__ScalaJSExportsNamespace`. Use `__ScalaJSEnv.exportsNamespace` instead.
Note that we cannot use the AutoPlugin in our build itself, because we need the *abstract* set of settings. However, the AutoPlugin is tested in sbt-plugin-test.
Phantom com fixes
This hopefully simplifies build definitions that need to tweak some command line options or just force a given environment. At the same time, this also fixes scala-js/scala-js#1302 (use proper class loader for PhantomJSEnv in our CI).
Rename former RuntimeDOM to RuntimeDOMDep to avoid import conflicts.
New test interface
…SEnv API. `JSEnv#jsRunner` and friends `asyncRunner` and `comRunner` now only take a `Seq[VirtualJSFiles]`, containing all JS files to be given to the JS environment. The JS environments therefore make no distinction between "library" files and the "code" file. The disinction was arbitrary anyway, and unifying them makes sure that all the JS files are first-class. In particular, it forced to solve shortcomings in terms of error handling in `JSDOMNodeJSEnv`.
…nker). The previous test had basically been inhibited when we switched the default environment from Rhino to Node.js. Indeed, this caused `loadedJSEnv` not to use the linker itself, but rather depend on the result of `fastOptJS`. The test was therefore not testing anything anymore. We restore this test in a more explicit and robust way, with a custom task to concurrently use the linker of `fullOptJS`, and a dedicated test task to directly depend on the former + `fullOptJS`. We use `fullOptJS` instead of `fastOptJS` because it takes more time, increasing the likelihood of concurrent execution.
…loadedJSEnv. We remove `resolvedJSEnv` simply by initializing `jsEnv` by default in the project scope, and using `jsEnv` instead of `resolvedJSEnv`. We remove `loadedJSEnv` by using instead the pair `jsEnv` + `jsExecutionFiles` explicitly. Finally, we can remove `JSEnv.loadLibs`, as it was only useful for `loadedJSEnv`.
Only trivial merge conflicts. Additionally, the partest `run/t1430` and `run/t4729` are moved to the blacklist in 2.12.2 and 2.13.0-M1. This brings those two versions up to par with 2.12.0 and 2.12.1, for which they had been blacklisted in 497e463.
3b54dbd
to
f148967
Compare
Phew ... managed to get it green. I had to resort to using coursier on Travis, because the normal ivy resolution was simply killing all the time allocated to jobs on Travis! Ping @gzm0. Since it's a new repo, I'm not sure you received earlier notifications. |
Will the references to issues "in the future" (e.g. If yes, consider I'm still reviewing the rest. |
The longer I think of it, the more unsure I get about importing the history. I do not understand what it buys us. IIUC, those commits won't build anyways, so we will not have bisecting capabilities or something. Have you considered just replacing everything with a commit saying "copied from scala/scala@..."? Yes, that would make us lose the history if we lose Scala.js, but then again, this would make this repo quite useless. Ok, I now understand that it gives us blame capabilities. So maybe we should retain it. I'll proceed with reviewing the filter branch procedure and the last commit. |
Yes, it's essentially for the blames. |
Hum, good point. Yes, I think you're right and we should rewrite those. |
If you are doing this and you need to repeat step 3 and step 4, note that I think they are just a convoluted way to do a |
Nah I'll do that as a step 5. A |
Ah, ah, indeed. |
.travis.yml
Outdated
- oraclejdk8 | ||
install: | ||
- mkdir -p $HOME/.sbt/0.13/plugins/ | ||
- echo 'addSbtPlugin("io.get-coursier" % "sbt-coursier" % "1.0.0-RC3")' > $HOME/.sbt/0.13/plugins/coursier.sbt |
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.
Consider commenting why you need coursier.
sbt ++$TRAVIS_SCALA_VERSION testAdapter/publishLocal sbtPlugin/publishLocal && | ||
sbt ++2.11.11 compiler/publishLocal library/publishLocal testInterface/publishLocal | ||
fi | ||
- cd .. |
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.
Just to double check, this will all go away (starting at git clone .../scala-js.git
) once we have a published version of SJS 1.x, right? (comment?)
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.
Yes, indeed.
directories: | ||
- $HOME/.ivy2/cache | ||
- $HOME/.sbt | ||
- $HOME/.coursier/cache |
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.
Just to double check: Neither ivy nor coursier copy local artifacts to the cache? Otherwise this would be a problem, right?
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.
No they don't ;) (I checked). Even if they did, each new publishLocal
would override the previous thing anyway, and they would have to use the updated one, because otherwise it would simply be unbearable even for local iterative development.
This is the initial import of the PhantomJS env and its sbt plugin from the Scala.js core repository. The history of this commit reflects the entire history of relevant files from the core repo, filter-branch'ed to appear as if they had always been in this repo. This commit adds the specific setup of the build and tests.
Updated:
|
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.
LGTM!
This is the initial import of the PhantomJS env and its sbt plugin from the Scala.js core repository. The history of this commit reflects the entire history of relevant files from the core repo, filter-branch'ed to appear as if they had always been in this repo. This commit adds the specific setup of the build and tests.
The history was obtained as follows, starting from commit scala-js/scala-js@f21e7f5 of the core repo.
First, we identified all the paths where relevant files have lived in the past, through renamings along their history. This is the list:
Based on that, we filter-branch'ed to keep only those files, using the following incantation, inspired by http://stackoverflow.com/a/6006679/1829647:
That gave the result visible in https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step1. Unfortunately,
--prune-empty
does not prune empty merge commits. We fixed that using the solution found in http://stackoverflow.com/a/38420284/1829647:git filter-branch --prune-empty --parent-filter 'sed "s/-p //g" | xargs -r git show-branch --independent | sed "s/\</-p /g"'
giving https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step2
Now, we had a clean history, except that it was orphaned wrt. the Initial commit of this repository, which is 51c45de. To have a nice PR with a history that appears to have come from the Initial commit, we reattached the first meaningful commit to the Initial commit using:
git filter-branch --parent-filter 'sed "s/ca1d58a31e27756c0d07fd65fbfdb1a3e0c6642e/51c45de4e5079a999abe964bc0e06dadcac8e789/"'
which yielded https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step3.
Almost there, except that now the files from the Initial commit have been removed in the first meaningful commit of the filter-branch. We restored them using:
git filter-branch --index-filter 'git reset 51c45de4e5079a999abe964bc0e06dadcac8e789 -- .gitignore LICENSE README.md'
giving the history in https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step4.
As a final polish, we rewrite, in commit messages, references to tickets of the form
#123
toscala-js/scala-js#123
, so that they point to issues in the scala-js/scala-js repository. This is done using the following incantation:git filter-branch --msg-filter 'sed -r -e "s/(#[0-9]+)/scala-js\/scala-js\1/g"'
and gives the result in https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step5.
This PR is one commit on top of that final step.