After updating my aurelia-dependency-injection library with Yarn, I started getting the following errors in my Jest tests.
It seems that for some reason the dependency injection library isn't working as expected?
● Datepicker › click date icon opens calendar
Loader must implement loadTemplate(url).
at Loader.loadTemplate (node_modules/aurelia-loader/dist/commonjs/aurelia-loader.js:119:11)
at ensureRegistryEntry (node_modules/aurelia-templating/dist/commonjs/aurelia-templating.js:3382:17)
at ViewEngine.loadViewFactory (node_modules/aurelia-templating/dist/commonjs/aurelia-templating.js:3456:12)
at RelativeViewStrategy.loadViewFactory (node_modules/aurelia-templating/dist/commonjs/aurelia-templating.js:562:23)
at HtmlBehaviorResource.load (node_modules/aurelia-templating/dist/commonjs/aurelia-templating.js:4238:27)
at ResourceDescription.load (node_modules/aurelia-templating/dist/commonjs/aurelia-templating.js:3258:26)
at ResourceModule.load (node_modules/aurelia-templating/dist/commonjs/aurelia-templating.js:3200:23)
at node_modules/aurelia-templating/dist/commonjs/aurelia-templating.js:3587:41
The issue was that my yarn.lock file had duplicate aurelia-dependency-injection references:
aurelia-dependency-injection#^1.0.0, aurelia-dependency-injection#^1.3.1:
version "1.4.1"
resolved "https://private-yarn-mirror/aurelia-dependency-injection/-/aurelia-dependency-injection-1.4.1.tgz#fb916e1809446600fb2cdf062f549060df49ef86"
dependencies:
aurelia-metadata "^1.0.0"
aurelia-pal "^1.0.0"
aurelia-dependency-injection#^1.4.2:
version "1.4.2"
resolved "https://private-yarn-mirror/aurelia-dependency-injection/-/aurelia-dependency-injection-1.4.2.tgz#fa9d1a9f4931e353fb8f938ee0c54b9fbf3f341a"
dependencies:
aurelia-metadata "^1.0.0"
aurelia-pal "^1.0.0"
My solution was to simply delete the top reference so that my yarn.lock looked like so:
aurelia-dependency-injection#^1.4.2:
version "1.4.2"
resolved "https://private-yarn-mirror/aurelia-dependency-injection/-/aurelia-dependency-injection-1.4.2.tgz#fa9d1a9f4931e353fb8f938ee0c54b9fbf3f341a"
dependencies:
aurelia-metadata "^1.0.0"
aurelia-pal "^1.0.0"
I then executed the following command to ensure the yarn.lock would generate correctly after my manual edit.
yarn add aurelia-framework#latest
After doing so, my yarn.lock looked like this:
aurelia-dependency-injection#^1.0.0, aurelia-dependency-injection#^1.3.1, aurelia-dependency-injection#^1.4.1, aurelia-dependency-injection#^1.4.2:
version "1.4.2"
resolved "https://private-yarn-mirror/aurelia-dependency-injection/-/aurelia-dependency-injection-1.4.2.tgz#fa9d1a9f4931e353fb8f938ee0c54b9fbf3f341a"
dependencies:
aurelia-metadata "^1.0.0"
aurelia-pal "^1.0.0"
Now my Jest tests work fine and everything is working elsewhere as well.
I discovered this article shortly afterwards which discusses the issue, though I personally didn't use the tools there:
https://medium.com/#scinos/de-duplicating-yarn-lock-ae30be4aa41a
Related
I have a huge project, which I was will simplify for the issue, with 2 workspaces.
The main packages looks like
workspaces: [ 'workspace-A', 'workspace-B' ]
My workspace-A has a dependency to external package (here, jest), in a needed version
name: "workspace-A",
dependencies: {
"jest": "<27.0.0"
}
My workspace-B has a dependency to the same package, but doesn't care about its version.
name: "workspace-B"
dependencies: {
"jest": "*"
}
After a yarn install (with yarn v3), I was expecting yarn to automatically install jest with a 26.x.x version in my main node_modules.
Instead, the node_modules of the main project contains jest 26.x.x, and the node_modules of the workspace-B contains jest 27.x.x. It's OK for my, even if I find this weird, but the thing is the workspace-A now uses jest 27.x.x!
I succeeded make it work by adding a resolution field in the main package file, but it's not ideal, as this package doesn't need jest.
"resolutions": {
"jest": "^26.6.3",
}
My 2 questions are
Why is yarn installing 2 versions of jest, is there a way to prevent this?
Is there a configuration somewhere I should put to specify to the workspace-A to not use something from workspace-B?
Thanks for reading
I am trying to follow the instructions in this repository to patch Jest.
Patch Jest.
It is suggested to use patch-package but I figured out that I can use yarn patch when using Yarn 2.
I managed to patch jest-runtime but seems Jest doesn’t seem to require jest-runtime in its package so I don’t know where it comes from to use it as a reference to declare the patched file.
Jest package.json
I understand if Jest was the one that needs to be patched I could declare it like this:
package.json
"devDependencies": {
"jest": "patch:jest#26.6.3#./patches/jest.patch"
}
I tried to use the same logic to include the following code to include jest-runtime but it didn't work.
"devDependencies": {
"jest": "^26.6.3",
"jest-runtime": "patch:jest-runtime#26.6.3#./patches/jest-runtime.patch"
}
How can I declare this patched jest-runtime so Jest can use it?
The Resolutions field in the manifest is the correct approach to declare the patched modules that we didn't add to devDependencies such as submodules.
The resolutions field allows you to instruct Yarn to use a specific resolution instead of anything the resolver would normally pick. This is useful to enforce all your packages to use a single version of a dependency, or backport a fix.
The fix for that issue:
{
...
"dependencies": {
"jest": "^26.6.3",
},
"resolutions": {
"jest-runtime": "patch:jest-runtime#26.6.3#./patches/jest-runtime.patch"
},
}
I'm getting an error repeatedly when trying to build a new webpack project using vue-cli. I'm following along with the docs on the latest build (3.0.0-beta.11), also tried with an earlier version, which wasn't beta.
When I run yarn serve it attempts to start the dev server and build the project but fails here:
error in ./src/App.vue?vue&type=template&id=7ba5bd90
Module build failed: Error: No parser and no file path given, couldn't infer a parser.
at normalize (/Users/cory/Code/chickadee/my-project/node_modules/prettier/index.js:7051:13)
at formatWithCursor (/Users/cory/Code/chickadee/my-project/node_modules/prettier/index.js:10370:12)
at /Users/cory/Code/chickadee/my-project/node_modules/prettier/index.js:31115:15
at Object.format (/Users/cory/Code/chickadee/my-project/node_modules/prettier/index.js:31134:12)
at actuallyCompile (/Users/cory/Code/chickadee/my-project/node_modules/#vue/component-compiler-utils/dist/compileTemplate.js:93:29)
at compileTemplate (/Users/cory/Code/chickadee/my-project/node_modules/#vue/component-compiler-utils/dist/compileTemplate.js:26:16)
at Object.module.exports (/Users/cory/Code/chickadee/my-project/node_modules/vue-loader/lib/loaders/templateLoader.js:42:20)
# ./src/App.vue?vue&type=template&id=7ba5bd90 1:0-194 1:0-194
# ./src/App.vue
# ./src/main.js
# multi (webpack)-dev-server/client/index.js (webpack)/hot/dev-server.js ./src/main.js
About my setup
Mac OS
I'm running node v8.5.0
packages are installed with yarn
The Things I've Attempted
Different versions of vue-cli to generate a new project. The projects generate and install modules.
Tried removing the prettier module, but the error still seems to come up.
Tried reinstalling all modules.
What else might I try to get past this error?
Removing the current node_modules folder from the project, adding "prettier": "^1.12.1" to package.json and running npm install solved the issue.
Another option is to run npm install prettier#1.12.1 without removeing the node_modules folder before
Update:
For some users, verion 1.12.1 did not work
#Kivin proposed another solution that can be found here: vue webpack template missing parser
Known issue and it will be fixed in the next version of vue-cli
In prettier 1.13.0, default parser was removed with a minor version(used to be babylon)
Issue: https://github.com/vuejs/component-compiler-utils/issues/14
Issue at prettier repo: https://github.com/prettier/prettier/issues/4567
Sorry, we committed the age-old semver sin- we knew this was a breaking change, but because it would only affect a subset of our users, we didn't bump the major version, because we didn't want to create friction for our users to upgrade.
To get the old behavior, add parser: "babylon". You may also want to lock prettier to a specific version in your package.json.
Running npm install prettier#1.12.1 solved it for me. Thanks lsxliron.
Right now, I tried all the options..downloading and updgrading prettier...but none workied. Until I studied what happened carefully.
Apparently, the prettier team removed the default parser which was babylon and in so doing...broke the internet.
Just kidding.
Issue repo
The simplest solution, according to them would be to simply add the parser back.
This has been picked up by the Vue team and its expected to be shipped with the latest fix release.
If you are using Vue Loader/Yarn, dont even bother to try all the suggestions...I tried them all.
What fixed it for me was...go to
node_modules\vue-loader\lib\template-compiler ...open index.js and look for
// prettify render fn
if (!isProduction) {
code = prettier.format(code, { semi: false})
}
and change the lines to:
// prettify render fn
if (!isProduction) {
code = prettier.format(code, { semi: false, parser: 'babylon' })
}
Thats it!
Then once the issue got fixed, everything will just be rolled back and you will still be fine.
Try this...it will save you countless minutes of searches....
As already pointed out by the various resonses, you may need to rollback the version of the prettier package.
in your package.json file, you may need to force npm to use a version (i.e. remove the hat ^)
mine looks something like this
"devDependencies": {
"prettier": "1.12.1",
"typescript": "^2.6.1",
"vue": "^2.5.16",
"vue-styleguidist": "^1.4.4",
"vue-webpack-loaders": "^1.0.6",
"webpack": "^3.1.0"
I have a project that uses Typescript, using the newer #types/foo style of installing typings packages.
When my build server installs all npm modules, sometimes I get a complete failure when compiling the typescript as some dependent definitions are no longer matching up.
For instance, I now have a problem with #types/gulp. In its package.json, dependencies are listed as:
"dependencies": {
"#types/node": "*",
"#types/orchestrator": "*",
"#types/vinyl": "*"
},
But now #types/orchestrator has updated, and it now breaks the version of #types/gulp that I have defined in my apps package.json.
How am I supposed to lock down version of dependencies like this so I no longer get this problem, or is there another workaround?
Unfortunately, I suddenly get these issues which sets development back by hours trying to sort it out. This makes using Typescript in a fast moving environment difficult.
How am I supposed to lock down version of dependencies like this so I no longer get this problem
Run npm shrinkwrap or just specify an exact version:
"#types/vinyl": "6.3.12"
If my package has these dependencies
{ "name": "my-package",
"dependencies": { "foobar":"~1.0.3", "baz":"2.0.9" }
And the foobar package has these dependencies
{ "name": "foobar",
"dependencies": { "baz":"^2.0.0" }
and the most recently released version of baz is 2.1.0, the first run of yarn will install baz#2.1.0 in foobar/node_modules.
How do I force yarn to use the baz#2.0.9 package for foobar?
My understanding is that this would be possible using npm shrinkwrap (a la this question).
The summary of my question probably is: Yarn creates repeatable, deterministic installations, but how do I customize that installation?
If you do in fact have a sub-dependency that is overly restrictive in what versions it will accept, you can override them using yarn.
UPDATED EDIT: Yarn now, as of 1.0, officially supports the "resolutions" block. So the way to override resolutions is to just add a block like this to package.json:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
You'll get warnings for "incompatible" versions sometimes, but I find that some packages (like socket.io) are overly restrictive in what version they accept, and so I'll happily select the latest version when it doesn't actually break things.
Original but outdated answer below.
It sounds like the original question wasn't exactly correct, but the original question was in fact the one I wanted answered, and I found an answer, so here it is for posterity:
I'm using the socket.io library, and it has component-emitter as a dependency. But it has a pair of versions that it requires. This is what the yarn.lock file looked like before I changed anything:
component-emitter#1.1.2:
version "1.1.2"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.1.2.tgz#296594f2753daa63996d2af08d15a95116c9aec3"
component-emitter#1.2.0:
version "1.2.0"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.0.tgz#ccd113a86388d06482d03de3fc7df98526ba8efe"
So it was including two copies of the component emitter in my client code. I looked, and there didn't appear to be any breaking changes between 1.1.2 and 1.2.0 (or 1.2.1, which was current). I first tried just changing the yarn.lock file:
component-emitter#1.2.1, component-emitter#^1.2.1, component-emitter#1.1.2:
version "1.2.1"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.1.tgz#137918d6d78283f7df7a6b7c5a63e140e69425e6"
This worked, but the file has warnings about it being autogenerated, meaning that every single update or new package I add will stomp on this change. A bit of searching found the yarn --flat option, which will force yarn to choose no more than one of each package in the entire project. That seems like overkill to me, since I'm sure there are actual cases of incompatibility between older and newer packages. I just wanted to eliminate a redundant package from my client code, to make the download smaller; I still want the development packages to all work correctly.
But in the docs to yarn --flat I found a reference to a "resolutions" block that can go in package.json:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
So I tried putting "component-emitter" : "1.2.1" in a new "resolutions" block in my package.json, and it in fact flattened component-emitter to 1.2.1 for all places that required it, and now I have only one copy in my client code.
(And now the resolutions block is completely supported in yarn, so you don't even need to use --flat.)
This is now possible with yarn's selective version resolution feature.
In your project's package.json, use resolutions:
"resolutions": {
"foobar/**/baz": "2.0.9"
}
This overrides package foobar's (and any other packages under it) version of baz, forcing it to be version 2.0.9.
EDIT: This is now deprecated, please read this answer instead:
https://stackoverflow.com/a/46615878/2398593
#SomeCallMeTime's answer is great and we've been doing that for month at work.
Unfortunately, this is not possible anymore since the v0.24.x (see that comment).
There's an opened PR on Github with an RFC proposal to have a simple way of handling that use case without having to keep an eye on the generated lockfile.