Need to be able to build using yarn as part of the build.
Yarn essentially replaces npm as our node-based package manager.
Postponed on #2874027: Install yarn on host environments (sorta, we could still do this, but it'd be easier if we didnt have to install it ourselves more than once)
Alternately, also add an install-yarn step for use until #2874027: Install yarn on host environments happens. Instructions: https://yarnpkg.com/lang/en/docs/install/#linux-tab
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 2874028.yarnbroken.patch | 358 bytes | Mixologic |
Comments
Comment #2
mile23We need to build JS for core using yarn.
Then we might need to run pure-JS tests using yarn or npm or whichever tool is most appropriate: #2869825: Leverage JS for JS testing (using nightwatch)
Comment #3
mile23@drpl in IRC:
Mile23: The thinking with the nightwatch.js work is to actually test JS with JS, especially now that browser automation libraries have gotten so good and Phantom has lost its maintainer.
Mile23: It just so happens that you can automate the install process of the headless version of Chrome (targeted for your arch) with npm/yarn and then run the tests in parrarel.
Comment #4
mile23Move forward on #2866840: Use stylelint as opposed to csslint in DrupalCI once we have this.
Comment #5
mile23Comment #7
mile23This branch does the following:
Adds a
yarn_installplugin at the very top. This step usesnpmto install yarn, which isn't the best way to install it, but is the easiest. This is a stop-gap until yarn is in the environment after #2874027: Install yarn on host environments https://yarnpkg.com/lang/en/docs/install/#alternatives-tabAdds a
yarn_buildplugin which executes if there's apackage.jsonfile.PoC
yarn.ymlbuild definition: http://cgit.drupalcode.org/drupalci_testbot/tree/build_definitions/yarn.... Run it this way to see it happen:DCI_LocalBranch=8.4.x DCI_UseLocalCodebase=/var/lib/drupalci/drupal-checkout ./drupalci run yarnBe sure and do a git fetch in the local source repo, oryarn_buildmight not find the lock file.Modifies this:
public function getTrueExtensionSubDirectory($use_core_directory_for_core = FALSE);This allows you to tell the method to give you backcore/for Drupal core. This simplifies hunting for config files.And speaking of hunting for config files, there's a new base class:
\DrupalCI\Plugin\BuildTaskForConfigBaseIt's a common pattern to only perform a task if there's a config file, so this starts putting all the config-hunting code in one place.Comment #8
mile23Comment #9
dawehnerI think we should maybe focus on Npm5 as this seems to be more than future than yarn.
Comment #10
dawehner@drpal convinced me that yarn is the right step at the moment. Please ignore my comment.
Comment #11
mile23Giving this a bump because #2874027: Install yarn on host environments is in.
Comment #12
mile23Interesting problem for the testbot. It can't install all the yarn dependencies because linux: #2915221: npm/yarn install fails due to eslint-config-airbnb
Piping some testbot output says: "yarn install v1.3.2[1/4] Resolving packages...[2/4] Fetching packages...info fsevents@1.1.1: The platform "linux" is incompatible with this module.info "fsevents@1.1.1" is an optional dependency and failed compatibility check. Excluding it from installation.[3/4] Linking dependencies...[4/4] Building fresh packages...Done in 5.03s."
Comment #14
mile23Renamed YarnBuild to YarnInstall since it's the
yarn installcommand.Has a default config to never die on fail, but still tells the log.
Comment #15
MixologicIm gonna review and stuff.
Comment #18
MixologicHeres a patch that makes yarn fail that Im going to use to test tangled yarnballs.
Comment #19
MixologicOkay, so I reviewed this and massaged it into dev.
Some things changed: I decided to focus on making this a "core yarn install" tool for now, and not concern ourselves with whether or not a contrib module comes with a package.json yet. There's only a few that do, and its unclear what, exactly, contrib is using those for.
It does bring up the same 'core is a platform vs. core is a project' dilemma where the question of whether or not core should *provide* developement tools and resources (like, say codesniffer rules) to subordinate projects, or whether those projects should define their own stuff.
package.json is another good example of this. Should contrib expect to have everything in *cores* package.json available during testing and development? or should contrib behave as if it were on its own and manage its own package.json?
The other thing I saw was the BuildTaskConfigurableBase - Im really not wanting to make a subclass hierarchy for extending things. BuildTaskBase should really only ever be it. If a group of buildtasks have a common functionality they need, that should be thrown into a Trait.
Finally, theres some terribly named things in there, and some awkwardly abstracted concepts. "getTrueExtensionSubDirectory" is probably the worstly named thing I've done in here.
What we're really trying to figure out is the "Root directory of the project under test" -> that can be /core, or wherever the extension ended up being installed to. In all use cases, we *either* need the "Root directory", *or* we need the *SourceDirectory*. Right now there is a mess of places where we're checking if the project is 'drupal', if its an extension test, and whether or not getTrueExtensionSubDirectory returns a blank, so straightening that/cleaning that up is definitely a great idea, but I dont think we need it for this yarn step.
Anyhow this merged into dev fine and tests ran (also added a couple of tests) so core now runs a yarn build step.
This is now in production, so we have yarn installing. Next up, yarn testing.
Comment #20
Mixologic