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"
Related
new to webpack configurations. I'm getting this error in my app and it doesn't compile. According to countless suggestions from SO, I've tried the setting (or variations of it) in my package.json:
"browser": {
"fs": false,
"net": false
}
And in webpack.config:
node: { fs: 'empty',
net: 'empty' }
It compiles but all it does is it has the file go blank on localhost.
Webpack version: 4.46.0
Node: 16.14.0
Windows 11
Any help greatly appreciated.
Webpack will let you bundle up modules of browser-compatible code into a production bundle for sending to the browser.
The fs and net modules are not browser-compatible code. They depend on APIs which are provided by Node.js and which are not provided by browsers.
Thus attempts to bundle them error, and if you tell webpage to treat them as empty then the generated bundle won't include them.
Make sure you are not importing the following from express or even json or something else
import { response } from 'express'
For anyone who is using React (happened to me in react). I have even read with NextJs this works but haven't tested it.
Man I did everything like config-overrides and node modules webpack config file updates and also changed react-scripts version 5 to 4 but nothing worked. But as soon as I removed response. It worked.
That one line only made me go into 7 hours of debugging mode.
But always enjoy it :)
It took me while to figure it out and I found out that it may be due to incompatible Node-gyp and Node-sass packages.My app is running fine now.
Again, the errors:
"Module not found: Error Can't resolve "fs" in..."
"Module not found: Error Can't resolve "net" in..."
Try this in the following order :
Delete package.lock.json
Update/install these packages to make them compatible with each other.
These versions worked for Node 16.14.0:
"node-sass": "^6.0.0"
"node-gyp": "^7.1.0" (in my case - npm install -g node-gyp#7.1.0)
"sass-loader": "^10.0.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.
In my nodeJS project suddenly it give error.I do not any upgrade or changes.
When I write NPM start in command line it give that error
ERROR in ./~/css-loader?sourceMap!./~/postcss-loader!./~/sass-loader?
sourceMap&outputStyle=expanded&includePaths[]=c:/TFS/rc1/app/scss&includePaths[]
=c:/TFS/rc1/~/compass-mixins/lib&sourceMap&sourceMapContents=true!./app/scss/_toolkit.scss
Module build failed:
undefined
^
Functions may not be defined within control directives or other mixins.
in c:\TFS\rc1\node_modules\compass-mixins\lib\compass\functions\_lists.scss (line 81, column 3)
# ./app/scss/_toolkit.scss 4:14-337
I reinstall compass-mixins package but it still give same error.Then I looked _lists.scss that file in 81 line there is a code .I deleted that bu it give same error.What should I do?
#if not(function-exists(compact)) {
#function compact($vars...) {
$list: ();
#each $var in $vars {
#if $var {
$list: append($list, $var, comma);
}
}
#return $list;
}
}
I also face the similar problem. And my project is using gulp-sass and compass-mixins. As heart.cooks.mind points out that, gulp-sass is depending on node-sass. And node-sass upgrade one of its dependence libsass to version libsass 3.3.3 Delorean since node-sass 3.5.1.
However, one of libsass 3.3.3 Delorean changes is related to this problem:
'Disallow functions to be defined in control directives or mixins (#mgreter, #1550)'
Obviously, _lists.scss in compass-mixins break this rule. Seems someone raise an issue to compass-mixins and they have idea on fixing it.
Before compass-mixins release the issue fixed version, my temporary workaround is to delete node_modules/node-sass manually and npm install node-sass#3.4.2
I had the same issue,please refer to node sass release 3.5.3 is breaking build and force lock gulp-sass to use the specific node sass library using shrinkwrap and avoid using the buggy version of node sass
I am using Gulp. Version 2.3.0 of gulp-sass breaks it. Go back to Version 2.2.0 and you are all fixed.
Edit:
The real culprit is the node module inside the "gulp-sass" node module known as "node-sass". You can see inside "gulp-sass"'s package.json file that it simply pulling version greater than ^3.5.3.
Even if you go back and reinstall "gulp-sass" to 2.2.0, as I suggested earlier, the package.json file in there will still pull "node-sass" greater than ^3.5.3.
If I use the older version of "node-sass" 3.4.2 that error goes away. I don't know how to fix that in an automated way. In a pinch I was able to fix the problem by copying that folder (that is using 3.4.2) from a different project that works. Now it compiles.
Can someone smarter than me figure out a better way to accomplish this result?
What I (temporarily) did, was to install globally the node-sass v3.4.2, and then replace the gulp-sass version of node-sass (it is located within gulp-sass/node_modules) with this older one.
sudo npm install -g node-sass#3.4.2;
sudo cp -r /usr/lib/node_modules/node-sass/ /usr/lib/node_modules/gulp-sass/node_modules/;
Btw, there is a PR waiting to be merged for this. But if you want to use this today then there's a fork of the merge too.
If you want to use latter then just put compass-mixins: tjenkinson/compass-mixins in your package.json and all will be good.
Update:- There's also an npm package for the latter mentioned in the PR now
Update 2:- This should no longer be a problem with v0.12.8 now
I am attempting to install localForage into a node.js application (with Angular) and Browserify.
Here is a link to the localForage documentation
It appears that using localForage and angular-localForage causes a problem with browserify based around the use of 'require'
If I require the localforage.js file in the src file I get the following error:
Warning: module "promise" not found from "/Users/mgayhart/Sites/epson- receipts/bower_components/localforage/src/localforage.js" Use --force to continue.
If I require the localforage.js file in the dist file, I get the following error:
Warning: module "./drivers/indexeddb" not found from "/Users/mgayhart/Sites/epson- receipts/bower_components/localforage/dist/localforage.js" Use --force to continue.
Anyone know of a workaround to be able to move forward with these libraries?
There is an issue on github with this problem: https://github.com/ocombe/angular-localForage/issues/26
I'll be working on it soon, you can subscribe to the github notifs on this issue to know when it's fixed !
For me installing it through bower and using it with browserify-shim worked. So in package.json:
"browser": {
"localforage":"./src/lib/vendor/localforage/dist/localforage.min.js"
},
"browserify-shim": {
"localforage":"localforage"
}
And to expose it as an angular-service (if you don't want to use angular-localforage):
app.factory "localforage",-> require 'localforage'
I've just been having this issue myself tonight, but I think I found a fix.
Instead of trying to get the bower modules to work with browserify, why not just use npm like its made for?
npm install localforage
and then when you use require you don't have to give it the path
but it still didn't work for me until I copied the folder:
localforage/src/drivers TO localforage/dist/drivers
Then it found all the dependencies and worked like a champ!
Alternatively if you must use bower you could try to use the debowerify tranform w/ gulp:
https://github.com/eugeneware/debowerify