-
Notifications
You must be signed in to change notification settings - Fork 5
Import the jsDependencies plugin 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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A JS_DEPENDENCIES manifest file is added to each configuration classpath and exported in JARs. This way, libraries may declare what exact JS files should be included from a WebJar they depend on. (Or what JS files they provide themselves should be included). Example usages can be found in the build definitions for the jasmine-test-framework and the testing example. - This completely removes `importScripts` and fixes scala-js/scala-js#457 - The project's classpath is fully available even in the post package stages. This is necessary to allow for discovery of dependency manifests and JS libraries the project depends on.
The new API allows for classpaths to be partially linked (n.b. packageExternalDeps, this commit fixes scala-js/scala-js#609).
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.
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
…cyManifest. This is necessary for the sbt plugin to avoid recreating the JS_DEPENDENCIES file over and over again, constantly invalidating the output of fastOptJS and fullOptJS.
Partial paths written in jsDependencies (including just file names) are shorthands for the full relative paths wrt. the classpath entries. Different partial paths resolving to the same full relative paths are considered equivalent for dependency resolution and ordering. If a partial path does not resolve to a unique full relative path on the classpath, a JSLibResolveException is thrown.
…be used in a ProjectRef.
Fix scala-js/scala-js#1569: Allow crossProject's JVM and JS parts to be used in a ProjectRef
We use sbt's tag mechanism to prevent concurrent execution. The test failed 60 consecutive times before the change and succeeded 60 consecutive times after it on a 2 core machine.
…ntry Fix scala-js/scala-js#2198: Allow non-existent classpath entries
This sbt setting is true if and only if the current project is a Scala.js project. It is not meant to be written to by users (only to be read).
… attributes. The source maps of `fastOptJS` can now be accessed with `fastOptJS.value.get(scalaJSSourceMap).get`, and similarly for `fullOptJS`.
This is part of scala-js/scala-js#2839. * `PhantomJSEnv` and `RetryingComJSEnv` are sent to their own `phantomJSEnv` sbt project. * The settings and tasks used to construct the `ClassLoader` that loads jetty8 are extracted into a separate `AutoPlugin`, named `PhantomJSEnvPlugin`, in the sbt project `phantomJSEnvPlugin`. * The tests in `sbt-plugin-test` do not mix PhantomJS-related tests with other tests anymore (in particular `jsDependencies`).
This turns withDOM into a test for DOM support only, independent of `jsDependencies`.
…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.
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 497e46351ae264e8b5ce8ee650515971733f9ec7.
…e repo. PhantomJS support moved in the separate repository https://github.com/scala-js/scala-js-env-phantomjs.
The implementation of that feature was piggybacked on the `JS_DEPENDENCIES` file maintained for the `jsDependencies` mechanism. As the latter will be extracted in a separate sbt plugin, the required semantics information will not be part of all Scala.js artifacts, and will therefore be bogus. This means that the `checkScalaJSSemantics` feature would not do its job correctly anyway, and it is better to remove it than to give a false sense of security. An alternative would be to store the relevant information in a separate file, but I do not believe it is worth it. Reasonable Scala.js libraries should never require compliant semantics anyway. Moreover, I have never had any feedback mentioning that feature, which probably means no one ever saw that feature in action, so it is useless.
This is part of scala-js/scala-js#2841. * The contents of `org.scalajs.core.tools.jsdep._` are extracted in a separate project `jsdependencies-core`. * All the settings related to `jsDependencies` are extracted in a separate sbt plugin `JSDependenciesPlugin` in `jsdependencies-plugin`.
This is the initial import of sbt plugin for `jsDependencies` 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.
gzm0
approved these changes
Jun 3, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the initial import of sbt plugin for
jsDependencies
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 created in a similar way as for scala-js/scala-js-env-phantomjs#1. It based on commit scala-js/scala-js@cc6610b from the core repository.
Step 1: keep only relevant files and their history
Result: https://github.com/sjrd/jsdependencies/tree/import-from-core-step1
Step 2: remove empty merge commit
Result: https://github.com/sjrd/jsdependencies/tree/import-from-core-step2
Step 3: attach to the Initial commit of this repo
The initial commit is 9c45fa5
Result: https://github.com/sjrd/jsdependencies/tree/import-from-core-step3
Step 4: reset files from the Initial commit
Result: https://github.com/sjrd/jsdependencies/tree/import-from-core-step4
Step 5: rewrite references to issues to point to the core repo
Result: https://github.com/sjrd/jsdependencies/tree/import-from-core-step5