gulp-eslint not linting .js files inside of a dot directory - javascript

I have .js files inside of a dot directory that are not being linted by gulp-eslint.
Example: .foo/file1.js
I've confirmed that the glob is picking up the files inside of the dot directory.
gulp-eslint is passing successfully for the files inside of a parent dot directory even when an intentional error is introduced inside these files.
I've confirmed that directories without a . in the name of the directory (e.g. src/file.js, etc.) are failing linting, when the same intentional error is introduced.
My project structure is something like this:
project/
│
├── .foo/
│ ├──file1.js
│ └──file2.js
│
├── src/
│ ├──file1.js
│ └──file2.js
│
├── gulpfile.js
└── .eslintrc
Contents of gulpfile.js
const gulp = require('gulp');
const eslint = require('gulp-eslint');
gulp.task('lint', () => {
return gulp.src([ './src/**/*.js', './.foo/**/*.js' ])
.pipe(eslint({
configFile: './.eslintrc'
}))
.pipe(eslint.format())
.pipe(eslint.failAfterError());
});
Contents of .eslintrc
// Reducing down to a single, simple rule
{
"env": {
"es6": true
},
"rules": {
"quotes": [
"error",
"single"
]
}
}
Is there something incorrect in my config that is preventing the .js files inside of the dot directory .foo from being linted?
Thanks!

It looks to be a known "quirk" of eslint (as of 6.8.0).
The workaround (until a PR is merged to fix this) is to use an .eslintignore file to unignore dot directories explicitly:
#.eslintignore
!.foo

Related

How to copy files that do not need to be compiled in Gulp?

Suppose that my project is like this:
├── dist
├── src
│   ├── greeter.ts
│   ├── index.html
│   └── test.txt
└── tsconfig.json
Only greeter.ts need to be complied to dir dist, but how about other files? How to copy other files to dir dist?
here is my gulpfile.js:
gulp.task('ts',cb=>{
return gulp.src('src/**/*.ts')
.pipe(sourcemaps.init())
.pipe(tsProject())
.js
.pipe(babel({
presets: ['env']
}))
.pipe(sourcemaps.write())
.pipe(gulp.dest('dist'));
});
Create a another task to copy other files and add its dependency on other task
gulp.task('copyFile', function () {
return gulp.src([
'src/**/*', //Include All files
'!src/**/*.ts' //It will exclude typescript files
]).pipe(gulp.dest('dist'));
});
gulp.task('ts', ['copyFile'], cb => {
//Your existing code
});

Cannot find module with Webpack, Typescript, custom module directory

What I'm trying to do
I am wrote a dummy module my-component which essentially exports a single class Something. I placed it in app/modules/. Now I am tying to access it using the import Syntax from app/app.js:
import { Something } from 'my-component';
Expectation: With my current Webpack configuration (below) I would expect this to work.
Actual: This throws the error:
ERROR in [default] /<project_dir>/app/app.ts:1:26
Cannot find module 'my-component/Something'.
What I tried to fix it
I know the module in itself is defined correctly, because
I can import it using a relative path: import { Something } from './my-component'
I can import it as-is, if I move the module to node_modules/my-component.
The only combination that fails is importing it without a relative path from my modules/ directory. So I think the issue might be my Webpack configuration.
Setup Details
As you can see below, I have two directories listed as resolve.root:
project_dir/app
project_dir/node_modules
It seems to manage to resolve from node_modules, just not from app.
Project layout
Webpack
project_dir/
├── app/ context, resolve.root
│ ├── app.ts
│ └── my-component/
│ ├── index.ts
│ └── Something.ts
├── webpack.config.js
├── node_modules/ resolve.root
│ ├── ...
│ ├── ...
│ └── ...
└── dist/
└── ...
app/app.ts
import { Something } from 'my-component/Something';
app/my-component/index.ts
export { Something } from './Something'
app/my-component/Something.ts
class Something {
}
export { Something };
webpack.config.js
var path = require('path'),
ROOT = path.resolve(__dirname, '.');
module.exports = {
context: path.resolve(ROOT, 'app'),
entry: 'app.ts',
output: {
path: path.resolve(ROOT, 'dist'),
filename: '[name]-[hash].js'
},
module: {
loaders: [
{ test: /\.ts$/, loader: 'awesome-typescript' }
]
},
resolve: {
root: [
path.resolve(__dirname, 'app'),
path.resolve(__dirname, 'node_modules')
],
extensions: [
'', '.ts', '.js'
]
}
};
EDIT
Fixed the project layout.
Cannot find module
If you experience this issue with dynamic module loading using ESNEXT,
you have to add "moduleResolution": "node" to your tsconfig.json.
I found an easier solution than the previously accepted one:
In your typescript configuration, set the baseUrl in the compilerOptions:
tsconfig.json:
{
"compilerOptions": {
"baseUrl": "./app",
...
},
...
}
Explanation:
Webpack and Typescript use node module resolution by default, which is fine.
When setting up custom module folders though, you need to configure them in both the Webpack and the Typescript config.
Changes to the Webpack module resolution config are not propagated to the Typescript compiler.
Ok. I created a replica of your project structure. It seems that the case is that the import statement does not behave the same as the require, AND, webpack resolve.root config works as expected with it.
For the modules, change your import statements to require like this:
app.ts
// Define require function for TypeScript to know that it
// will exist at runtime
declare function require(name:string);
// Require your module
var Something = require('my-component/Something');
// var myComponent = require('my-component');
my-component/Something.ts
// Export something (used a function to test)
export function Something() {
console.log("Hello");
}
my-component/index.ts
// Definition of require function as mentioned before
declare function require(name:string);
// Passing other modules
var exportedModules = {
Something: require("my-component/Something")
};
export default exportedModules;
Like this, it will work without problems and resolve with the module names as you defined in Webpack. Unfortunately, I couldn't achieve it with the import.
I pushed the solution to a repository. Check it out if you need!

Webpack: Hide some modules printed by webpack --display-modules --display-reasons

Question
Is it possible to specify modules to be hidden (ignored) in printed output by webpack --display-modules --display-reasons?
Setup
structure
.
├── build
│   └── index.js
├── package.json
├── src
│   ├── hello
│   │   └── index.js
│   ├── index.js
│   ├── util
│   │   └── index.js
│   └── world
│   └── index.js
└── webpack.config.js
package.json
{
"private": true,
"scripts": {
"start": "webpack --display-modules --display-reasons"
},
"devDependencies": {
"babel-loader": "^6.2.4",
"babel-preset-es2015": "^6.9.0",
"webpack": "^1.13.1"
},
"dependencies": {
"core-js": "^2.4.0",
"lodash": "^4.13.1"
}
}
src/index.js
import hello from './hello'
import world from './world'
console.log(`${hello()} ${world()}`);
src/hello/index.js
import util from '../util';
const _ = require('lodash');
const hello = () => _.capitalize(`hello${util()}`);
export default hello
src/world/index.js
import util from '../util';
const _ = require('lodash');
const world = () => _.capitalize(`world${util()}`);
export default world
src/util/index.js
export default () => '!'
webpack.config.js
module.exports = {
entry: './src/index.js',
output: {
filename: './build/index.js'
},
module: {
loaders: [
{
test: /\.js?$/,
exclude: /node_modules/,
loader: 'babel-loader',
query: {
presets: 'es2015'
}
}
]
}
};
Motivation
By running webpack I get this stunning program in build/index.js which prints:
Hello! World!
More interesting part is in output printed by webpack --display-modules --display-reasons:
This output is very powerful:
immediately see project structure
recognise which modules are required by other modules
how many times those modules are reused
where those modules are required in other modules
used module format
is it my module or from node_modules
looks super cool
Mentioned above pros connivence me to use this output in daily work.
But can be problem with it.
Problem
When I use big external package with a lot of modules it can blur my output from previous picture. You can see it when add for example core-js to my files:
src/index.js (modified)
require('core-js'); // new problematic package
import hello from './hello'
import world from './world'
console.log(`${hello()} ${world()}`);
Now my output printed by webpack --display-modules --display-reasons looks like this:
This output is quite long (it's hard to scroll to top). core-js blooded my previously output and I lost mentioned previous pros of analyze it.
Tips
problematic output isn't always at the end
problem isn't related only with core-js (it's only example)
switching to pre-build sources isn't solution
require of problematic package must occurs in source .js files not in webpack.config.js
To exclude more than one folder add the following to webpack.config.js
stats: {
exclude: [
"node_modules",
"bower_components",
"jam",
"components",
"my-custom-folder"
]
}
without using --display-exclude
In webpack there is undocumented option --display-exclude which, as described in source code, exclude modules in the output.
This is exactly what you need, so, pass this parameter to webpack cli:
webpack --display-modules --display-reasons --display-exclude="core-js"

Webpack bundle named requirejs modules

In my company we have a significant AMD RequireJS code base and I am trying to use webpack to bundle some of it.
Here is what the architecture looks like:
somedir
│ app.js
│
└───anotherdir
|
├─── module1
│ file1.js
│ file2.js
│
├─── module2
│ file3.js
│
└─── module3
file4.js
file5.js
file6.js
Each file is written like that :
define('ATAG/MODULE/ID, ['somedeps'], function (somedeps) {});
So for instance file1.js could look like
define('ATAG/module1/file1, [], function () {});
And we have a RequireJS config which maps ATAG to anotherdir and we possibly have some more config for different tags.
Now I am trying to create a bundle from app.js with webpack but I have no idea of how to replicate the behavior we have with require.config({ paths: { ATAG: 'anotherdir' } }).
So far my attempts with resolve.alias have not been successful.
Is it even possible to achieve something like this with webpack based on our usage of RequireJS (not requiring relative paths) ?
Thank you.
You were on the right path with resolve.alias:
// foo.js
var a = require('ATAG'); // resolved to anotherdir/index.js
var b = require('ATAG/bar'); // resolved to anotherdir/bar.js
// webpack.config.js
const path = require('path');
module.exports = {
entry: './foo',
output: {
filename: 'bundle.js'
},
resolve: {
alias: {
ATAG: path.join(__dirname, '/anotherdir')
}
}
};

Gulp.js: how to rewrite relative paths?

Structure:
static
├── build
│ ├── css
│ ├── fonts
│ ├── img
│ └── js
└── src
├── blocks
├── fonts
└── img
Piece of gulpfile.js:
var path = {
build: {
js: 'static/build/js',
css: 'static/build/css',
fonts: 'static/build/fonts',
img: 'static/build/img'
},
src: {
vendor_fonts: ['bower_components/**/*.{svg,woff,eot,ttf}', 'semantic/**/*.{svg,woff,eot,ttf}'],
vendor_img: ['bower_components/**/*.{png,jpg,jpeg,gif}', 'semantic/**/*.{png,jpg,jpeg,gif}']
}
};
gulp.task('vendor:img', function(){
return gulp.src(path.src.vendor_img)
.pipe(imagemin({
progressive: true,
interlaced: true,
use: [pngguant()]
}))
.pipe(gulp.dest(path.build.img))
});
gulp.task('vendor:fonts', function() {
gulp.src(path.src.vendor_fonts)
.pipe(gulp.dest(path.build.fonts))
});
When i build 3-party packages (such as fotorama or semantic ui), they have a relative paths - as a result, main.css have only relative paths and server cant't find them.
How i can solve this?
If your gulpfile.jss is in your root you should be able to just prefix your paths with nodes Global Object __dirname
__dirname#
{String}
The name of the directory that the currently executing script resides in.
Example: running node example.js from /Users/mjr
console.log(__dirname);
// /Users/mjr
__dirname isn't actually a global but rather local to each module.
https://nodejs.org/api/globals.html#globals_dirname
So if your gulpfile was in your root in your paths just do
__dirname + "/build/whatever/whatever";
This all being if I understand your question correctly.

Categories