When I'm trying to build the Next.Js app then the below error is coming with a successful build. This error is showing when I deploy the app in Vercel.
error - ESLint: Failed to load config "next/babel" to extend from. Referenced from: /vercel/path0/.eslintrc.json
This is my .eslintrc.json
{
"extends": ["next/babel","next/core-web-vitals"]
}
I've also added .babelrc
{
"presets": ["next/babel"],
"plugins": []
}
I also found a solution when I change the eslintrc.json file like below:
{
"extends": ["next","next/core-web-vitals"]
}
then no error is showing while building the app. But there is another problem showing when I use the above solution and the problem is:
Parsing error: Cannot find module 'next/babel'
This is shown in all the imports with red marks.
I tried to search the solution but did not found any solution for this.
I think, this might have to do with this weird hackfix that is being touted in a bunch of places that tells you to place next/babel in your eslint config file for some reason (e.g. here).
It probably was a hackfix for an old bug in older next.js versions. But as of (at least) summer 2022, it makes little sense to do so, considering that next/babel is a babel preset, not an eslint preset. Instead, in recent next.js versions, just reset your .eslintrc.json:
{
"extends": [
"next"
]
}
With this setup, things don't error out, as of next#12.2.*.
You also might want to take a look next's eslint customization options. For example, some people might be confused why eslint is seemingly not working.
In that case, consider this solution and the next.js docs on eslint.
If you have this problem, but you did not copy+paste your .eslintrc.json from the interwebz, then you might need to describe your situation in more detail.
my problem has been solved by this code. just copy and paste it into the eslintrc.json file.
{
"extends": ["next/babel","next/core-web-vitals"]
}
Or just replace "next" and "next/core-web-vitals" to
"plugin:#next/next/recommended"
https://nextjs.org/docs/basic-features/eslint
I had this issue when working with TurboRepo. The solution for me was to add next as a devDependency in the root of the monorepo.
Same Turborepo issue using pnpm. This solved it for me: https://github.com/vercel/next.js/issues/40687#issuecomment-1275184829
Essentially add this to your settings.json
// .vscode/settings.json
{
"eslint.workingDirectories": [
{ "pattern": "apps/*/" },
{ "pattern": "packages/*/" }
]
}
Related
I know there are a lot of answers like this, this or this out there and some people may flag my question as duplicate, but believe me I am struggling with this because neither of them is working for me now. Those were working before but looks like the solution is depreciated or expired.
I have no idea about eslint whatsoever, the only thing I like about eslint is that it underlines the unimported/undeclared variables with red line, that's why I installed eslint extension in my VS Code editor.
Also, I am not opening the code directory directly in my VS Code, I have other projects too in the same workspace, e.g. I have a structure like this:
| -- some_folder
| | -- project_1
| | -- project_2
| ...files relating to both projects...
Starting a fresh Next.js project should not be coming up with any errors, don't know what am I doing wrong.
This is my .eslintrc.json:
{
"extends": "next"
}
And this is the .babelrc:
{
"presets": ["next/babel"],
"plugins": []
}
To tell exactly what type of solutions I already tried:
Adding next/babel in the .eslintrc.json
installing babel-eslint but nothing helped!
instead of this in eslintrc.json
{
"extends": "next"
}
use this
{
"next/babel","next/core-web-vitals",
}
I think this will fix the issue.
I have this folder structure:
sass/main.sass
css/main.css
js/...
img/...
I want the sass output to go to the css folder, but each time I run sass watcher it creates a new css file within the sass directory among sass files.
Thx for information about using 'Live SASS Compiler' in VS Code.
To set special otuput pathes to your project you need to add the settings for output pathes to the settigns.json of your project:
File: `projectDIR/.vscode/settings.json'
Example for setting the save pathes to output directory:
"settings": {
// output: generate files to ...
// ~ = path starts relative from scss-file
"liveSassCompile.settings.formats":[
{
"format": "expanded",
"extensionName": ".css",
"savePath": "~/../assets"
},
// ad a compressed version
{
"format": "compressed",
"extensionName": ".min.css",
"savePath": "~/../assets"
}
// optional: add more outputs ...
],
}
See also official example in web: https://github.com/ritwickdey/vscode-live-sass-compiler/blob/master/docs/settings.md
Additional hint:
VERSION OFF 'LIVE SASS COMPILER' MAY BE OUTDATED
The actual commmon used Extension Live Sass Compiler is not longer supported (for years now). It uses an outdated SASS Version. The most recent features like #use are not supported in that version. You use that outdated version if author is 'Ritwick Dey'.
But there is an active supported fork with same name 'Live SASS Compiler' build by 'Glenn Marks'. As fork it works the same way and the settings are almost the same. Or you can use another actual compiler which is faster as you can use an direct installed SASS Version on your system. In that case you need to change the settings for your project.
Information about that you will find here:
https://stackoverflow.com/a/66207572/9268485
Updated: Correction name of author of supported extension 'Live SASS Compiler' to correct identification of extension.
Go to path: C:\Users\your user\AppData\Roaming\Code\User\settings.json
and change there the "liveSassCompile.settings.formats" section
for example:
the parameter : "savePath": "/Python/CSS",
I'm using WebPack and now I'm going to need to do the compilation of SASS fiels (we'll be working with Bootstrap). First of all, I installed node-sass and sass-loader (not sure if any of those is needed at all). Then, in my server.js I've added the following line (nothing more that would refer to the Sass object, yet).
import Sass from "node-sass";
The compilation gave me errors that fs package is missing so based on this answer I've tried the following (both individually and simultaneously). The error about fs disappeared but instead there's something about unexpected token in the package.json of the node-sass module.
node: { fs: "empty" },
target: "node",
...
I have no idea what those would do and how those affect anything. Both seem to be produce the same error. Any light on that would be an extra bonus as they appear quite different from each other.
Then, I also tried to enable to the loader in my webpack.config.js by the following addition suggested here. Even tried to map the source like described here. Another post suggests using a different syntax for target specification... Nothing seems to help and finally I got totally confused and gave up.
module: {
loaders: [
{ test: /\.js$/, loader: "babel", exclude: /node_modules/ },
{ test: /\.scss$/, loader: 'style!css!sass' }
]
},
sassLoader: { sourceMap: true },
...
Some of the posts I'm reading are old and I feel that they might be outdated and do more harm than good. And there seems to be quite a few posts not answered that regard the connection between WebPack and SASS (e.g. this and this). I fear that I might be barking up the wrong tree...
I need help being pointed in the right direction.
There should be no need to write import Sass from "node-sass"; anywhere in your code. The node-sass package is part of your build-pipeline which is using webpack and thus running in a node environment. But your front-end code typically does not have any connection to a node env because it's running in the browser. This also explains why you got errors related to fs. You should also get rid of your node: { fs: "empty" }, target: "node", ... stuff. In a pure front-end related webpack pipeline you shouldn't need those hacks.
Try the following in your webpack.config.js file:
module.exports = {
...
module: {
loaders: [
{
test: /\.scss$/,
loaders: ["style-loader", "css-loader", "sass-loader"]
}
]
}
};
To get things going don't use source-maps from the beginning, but add them once the rest of the setup is running. To get sourcemaps each loader must re-use the result from the previous loader, which is why you should start with having a look how sourcemaps are configured for sass-loader.
Hi there I have been forced to come here due to every resource out there on the topic is very poor and incomplete.
Not only on the babel site but every single post out there is not complete and informative enough.
I tried to reach out at the babel forum and no replies.
I am trying to convert my prototype libraries to Es6 and convert to the most leanest possible code. So no bloaty duplicated generated code and if possible no bloaty requirejs and whatever browserify generates.
I have tried to make a project with grunt and babel directly, configure the external-helpers plugin according to the babel documentation.
It fails to include the relevant helper code and fails to include the import module code altogether.
ie a babel config like
{
options: {
sourceMap: false,
presets: ['es2015'],
"plugins": ["external-helpers"]
},
dist: {
files: {
'build/<%= package.name %>.js': ['src/<%= package.name %>.js']
}
}
}
The main project file has an import like
import Button from './ui/buttons/Button';
The module code looks like this as if the export is placed underneath extra code is generated for that.
export default class ShareButton {}
produces an output like this
Object.defineProperty(exports, "__esModule", {
value: true
});
require('babel-core/external-helpers');
var _Button = require('./ui/buttons/Button');
var _Button2 = babelHelpers.interopRequireDefault(_Button);
No source of the module or the helper object is included.
I searched hard for how to deal with external-helpers and it suggests it has to be imported into a separate file ie something like this to generate only the helper functions needed
babel-external-helpers -l createClass > src/helpers.js
But any resource regards to this fails to go as far as to how to import that into the project.
If I use the transform-runtime plugin, it produces a massive polyfill that cannot be disabled so a bug and not so useful for what I need.
"plugins": [
["transform-runtime", { "polyfill": false, "regenerator": false }]
]
If I use browserify / babelify it makes a royal mess and duplicates code still.
A config like
{
options: {
"transform": [["babelify", {
"presets": ["es2015"],
"plugins": ["external-helpers"],
sourceMap: false
}]]
},
dist: {
files: {
'build/<%= package.name %>.js': ['src/<%= package.name %>.js']
}
}
}
Produces code like this still with the external helper missing and duplicated code not relevant to the helper. ie
Object.defineProperty(exports, "__esModule", {
value: true
});
Is within every module in the generated file.
If I export the classes like this at the bottom of every file
export default class {}
Duplicated code is generated like
var _class = function _class() {
babelHelpers.classCallCheck(this, _class);
};
exports.default = _class;
In terms of filesize that doesn't include bloaty wrapping code like
},{}],2:[function(require,module,exports){
It seems concatting all the prototype classes files together to bundle in one file is the winner still.
So trying to port the library but keep it similar and bundle it together into one file.
Hopefully this is concise enough and there is a simple solution.
FYI browsers do not understand tabs and 4 spaces. I had to edit this post in my editor to get the code blocks working ! It would be nice to have a markup like other places like "```" ?
Let me know thanks.
I'm using rollup with babel now. Rollup produces a clean output as umd mode. Browserify is really bloaty in itself.
There is just a problem with polyfills being converted. I have to concat external ones in like for WeakMap.
I had a problem trying to use the generated Iterator and finding a polyfill for that so I have to code loops a particular way it doesn't generate Iterators.
The polyfill generation in babel is still too bloaty and crazy. It's pretty terrible. So I concat in minified polyfills that are very small and it's used globally.
I was running into something very similar. Was tired of trying to do it the "right way" and ended up just creating https://www.npmjs.com/package/grunt-babel-helpers which simply manipulates the string output.
I'm trying to use grunt-contrib-livereload, but can't seem to figure it out. The readme seems to skip over everything that I need explained, and then ends with an example that doesn't work when I try it and doesn't seem directly related to the documentation. I have searched for a better explanation in a blog post or tutorial or whatever, but haven't been able to find one. Can someone please explain how to get started with this tool?
Here are the kinds of questions I have, based on the readme:
The documentation says the livereload task "must be passed the list of files that have changed" --- but how do I pass it this list of files? The example does not seem to illustrate this. Does regarde pass the list?
Is grunt-contrib-connect required? What does it do, and how do I use it? Do I need to learn connect before I try using livereload?
The readme mentions middleware that "must be the first one inserted" --- but inserted into what, before what else? And how is it inserted?
And I suppose I don't understand how I need to manipulate ports. "All the browsers listening on the livereload port will be reloaded" --- but how do I know which browser is listening to which port? Do I need to learn all about ports before I can try using livereload? (Any suggestion on how to best learn about that?)
Finally, in the example, there is a folderMount function that doesn't seem related to any of the documentation before. What is that, and do I need it?
I guess I'm asking if someone can please:
point me towards a tutorial that is much more effective than the current readme;
explain these unexplained parts of the readme, if those answers are what I need to understand the plugin;
or provide a functional example with some explanation of why it is functional.
Live reloading is now built into grunt-contrib-watch version 0.4.0. grunt-contrib-livereload and grunt-regarde will be deprecated soon.
Now just set the option livereload to true in your config and it will create a live reload server then reload after the tasks have run:
grunt.initConfig({
watch: {
all: {
options: { livereload: true },
files: ['lib/*.js'],
tasks: ['jshint'],
},
},
});
By default the live reload server will be started on port 35729. So to enable live reloading on your page just add <script src="http://localhost:35729/livereload.js"></script> to your page.
View more info on the docs: https://github.com/gruntjs/grunt-contrib-watch#live-reloading
Edit: Check versioning info. grunt-contrib-watch now has livereload support baked in.
What a doozy. I ran into issues with this one too so let me do what I can to explain (or at least get you up and running). Keep in mind, this is how I have it set up and it seems to work most of the time.
For starters, you'll want to make sure you've udpated your package.json with the right dependencies. I'm not sure that livereload works with the baked in "watch" task and I've been using grunt-regarde of late. My package.json usually looks like this:
"dependencies": {
"grunt": "~0.4.x",
"grunt-contrib-livereload": "0.1.2",
"grunt-contrib-connect": "0.2.0",
"grunt-regarde": "0.1.1"
},
Obvi you want grunt (duhhh), livereload, connect seems to help with mounting folders, and regarde is like grunt-watch, it just seems to work better (I forget why exactly).
You could make your package.json even better by specifying livereload in its own "devDependencies" object if you're so inclined. Now, run your good old fasioned npm install to get the goodies in your project.
Let's talk gruntfiles:
As you probably know, the gruntfile is what makes the magic happen. Somewhere towards the bottom of your gruntfile, you'll want to specify
grunt.loadNpmTasks('grunt-regarde');
grunt.loadNpmTasks('grunt-contrib-livereload');
grunt.loadNpmTasks('grunt-contrib-connect');
At the top of your gruntfile, we'll want to add some utils for livereload. Under /*global module:false*/, go ahead and add var lrSnippet = require('grunt-contrib-livereload/lib/utils').livereloadSnippet;.
After that, you don't really need to learn connect, you just gotta use it. Check my style:
var folderMount = function folderMount(connect, point) {
return connect.static(path.resolve(point));
};
This comes before module.exports = function(grunt) {
Now let's get into the meat of the gruntfile. Again, I forget what connect is doing but this is where the middleware magic comes into play. In your modules.exports, add:
connect: {
livereload: {
options: {
port: 9999,
middleware: function(connect, options) {
return [lrSnippet, folderMount(connect, '.')]
}
}
}
},
Now we want to have the files watched. I like to set up a few different tasks since I don't want my whole grunt process running every time I save a CSS file. Here's what I work with (again, add to module.exports):
regarde: {
txt: {
files: ['styles/*.css', 'index.html'],
tasks: ['livereload']
},
styles: {
files: ['sass/*.scss', 'sass/*/*.scss'],
tasks: ['compass']
},
templates: {
files: ['templates/*.jade'],
tasks: ['jade']
}
},
You can see that I only want livereload to fire when there have been changes to my compiled css (*.css) or to my compiled html. If I edit a SCSS file, I want to fire off just compass. If I edit a jade template, I want to only fire the jade to HTML compiler. I think you can see what's going on. You can toy with this, just be smart about it because you could get caught in an infinite loop.
Lastly, you need to fire off these processes. I like tying them all to my main grunt task because my gruntfile is just that sweet.
// Default task.
grunt.registerTask('default', ['livereload-start', 'connect', 'regarde']);
Now, when you fire up grunt in the CLI, you should (hopefully, maybe, cross your fingers) get something like this:
Running "connect:livereload" (connect) task
Starting connect web server on localhost:9999.
Browse to http://localhost:9999/yourpage.html and watch magic happen.
full gruntfile here. full package.json here.
Here is a solution based on Gulp instead of Grunt and the following Gulpfile.js to get livereload working:
var gulp = require('gulp');
var connect = require('connect');
var connectLivereload = require('connect-livereload');
var opn = require('opn');
var gulpLivereload = require('gulp-livereload');
var config = {
rootDir: __dirname,
servingPort: 8080,
// the files you want to watch for changes for live reload
filesToWatch: ['*.{html,css,js}', '!Gulpfile.js']
}
// The default task - called when you run `gulp` from CLI
gulp.task('default', ['watch', 'serve']);
gulp.task('watch', ['connect'], function () {
gulpLivereload.listen();
gulp.watch(config.filesToWatch, function(file) {
gulp.src(file.path)
.pipe(gulpLivereload());
});
});
gulp.task('serve', ['connect'], function () {
return opn('http://localhost:' + config.servingPort);
});
gulp.task('connect', function(){
return connect()
.use(connectLivereload())
.use(connect.static(config.rootDir))
.listen(config.servingPort);
});
I know this is a little old but can help someone.
In the Gruntfile.js add "options":
sass: {
files: 'scss/**/*.scss',
tasks: ['sass'],
options: {
livereload: true,
}
}
In the index add:
<script src="http://localhost:35729/livereload.js"></script>