Develop Reference

Allow imports only from index file of folder, except inside the folder with import/no-internal-modules

Given the following folder structure:
my-project
├── components
│ └── getUser.js
│ └── updateUser.js
└── utils
└── models
│ └──index.ts
│ └──api.ts
└── services
└──index.ts
└──api.ts
└──price
└──index.ts
└──getPrice.ts
I would like to make sure that every filt outside of the services folder only imports from the service index file, like so:
import { getPrice } from 'utils/services';
but I would also like files inside the services folder to import from each other, for example that the api file can do import { getPrice } from './price';
I have this rule in the root .eslintrc
"import/no-internal-modules": [ "error", {
"forbid": [ "/**/util/services/*" ]
} ]
and inside the services folder I have another .eslintrc with this rule:
"import/no-internal-modules": [
"error",
{
"allow": [
"util/services/**"
]
}
]
But running this seems to do the exact opposite of what I want, right now it only gives error for all the files in the services folder, saying for example Reaching to "./price/get" is not allowed on a file inside the services folder.

gatsby-source-filesystem not sourcing files from site directory when used in a theme

I'm trying to build a gatsby theme that uses gatsby-source-filesystem to source images.
I have set up a yarn workspace for development, my folder structure looks like this.
workspace/
├─ example.com/
│ ├─ src/
│ │ ├─ pages/
│ │ │ ├─ test.js
│ ├─ gatsby-config.js
│ ├─ package.json
├─ gatsby-theme-example/
│ ├─ src/
│ ├─ images/
│ ├─ gatsby-config.js
│ ├─ gatsby-node.js
│ ├─ package.json
The yarn workspace is also set up correctly and the gatsby-theme-example is a dependency of it. yarn workspaces info correctly shows it in workspaceDependencies.
Both workspaces have a gatsby-config.js file, the gatsby-theme-example has the gatsby-source-filesystem in it.
{
resolve: `gatsby-source-filesystem`,
options: {
name: `images`,
path: path.join(__dirname, "images"),
},
},
The problem I'm facing is that I have to put the images inside the theme directories image folder, otherwise they are not found by gatsby-source-filesystem. From following this video and reading the tutorial, using path.join and the __dirname variable should point to the package that has the theme installed as a dependency, in my case example.com
Strangely, the gatsby-plugin-page-creator plugin in gatsby-theme-example/gatsby-config.js creates the pages defined in example.com/src/pages (the site directory) perfectly.
{
resolve: "gatsby-plugin-page-creator",
options: {
path: path.join(__dirname, "src/pages"),
},
},
I also have onPreBootstrap defined in gatsby-theme-example/gatsby-node.js like this
exports.onPreBootstrap = ({ reporter }) => {
const contentPath = `${__dirname}/images/`
if (!fs.existsSync(contentPath)) {
reporter.info(`creating the ${contentPath} directory`)
fs.mkdirSync(contentPath)
}
}
and it creates the images directory in gatsby-theme-example not example.com
I'm using gatsby#4.18.0 and gatsby-source-filesystem#4.18.0 and start the project using this command: yarn workspace example.com start
I've set up a repo, which you can use to reproduce the issue like this:
git clone https://github.com/AlexanderProd/gatsby-source-filesystem-theme-bug
yarn workspace example.com install
yarn workspace example.com start
go to http://localhost:8000/___graphql
run the following query
query MyQuery {
allFile {
edges {
node {
id
name
}
}
}
}

Not sure if this is supposed to be done that way but I found a workaround.
In the sites gatsby-config.js (example.com/gatsby-config.js) where the theme is specified, I added an option for the images path.
{
resolve: `gatsby-theme-example`,
options: {
imagesPath: path.join(__dirname, "images"),
},
},
and then in the themes gatsby-config.js I'm using the option value.
module.exports = options => ({
plugins: [
{
resolve: `gatsby-source-filesystem`,
options: {
name: `images`,
path: options.imagesPath,
},
},
]
})

Another solution and in this case the optimal one is to just use images as a path.
{
resolve: `gatsby-source-filesystem`,
options: {
name: `images`,
path: `images`,
},
},
Based on this answer.

Unable to require() from inside an already "required" module

I have this project structure:
myApp
├── gulpfile.js
├── package.json
└── source
   └── scripts
      ├── modules
      │ └── utils.js
      ├── background.js
      └── data.json
My browserify task:
gulp.task('browserify', function () {
return gulp.src(['./source/scripts/**/*.js'])
.pipe($.browserify({
debug: true,//for source maps
standalone: pkg['export-symbol']
}))
.on('error', function(err){
console.log(err.message);
this.emit('end');
})
.pipe(gulp.dest('./build/scripts/'));
});
My sample utils.js:
const data = require('../data.json');
const utils = (function () {
const output = function () {
console.log(data);
};
return {
output: output,
};
}());
module.exports = utils;
If I try to build it with the current directory structure, I get this error:
module "../data.json" not found from "/dev/myApp/source/scripts/fake_4d8cf8a4.js"
I can only build it, if I put data.json inside the modules directory AND inside the scripts directory, ie. it only works if I duplicate the file:
myApp
├── gulpfile.js
├── package.json
└── source
   └── scripts
      ├── modules
      │ ├── utils.js
      │ └── data.json
      ├── background.js
      └── data.json
Obviously this is not okay... what am I doing wrong?
Thank you

I'm inferring from your use of gulp.src to pass files to $.browerify that you are using a Gulp plugin, probably gulp-browserify. It is generally not recommended to use a plugin to invoke Browserify from Gulp. The recommended way to do it is to just call Browserify directly. Indeed, Gulp's blacklist of plugins states:
"gulp-browserify": "use the browserify module directly",
I've replicated your directory structure and put some reasonable values for the files for which you did not provide contents (data.json, background.js) and indeed, I get the same error you get when I try to run the Gulp code you show. However, if I switch to calling Browserify directly, I do not get any error. Here is the code I have:
const gulp = require("gulp");
const browserify = require("browserify");
const source = require('vinyl-source-stream');
gulp.task('browserify', function () {
return browserify({
entries: ["./source/scripts/background.js",
"./source/scripts/modules/utils.js"],
debug: true,//for source maps
standalone: "foo",
})
.bundle()
.pipe(source('bundle.js')) // This sets the name of the output file.
.pipe(gulp.dest('./build/scripts/'));
});
You use gulp.src(['./source/scripts/**/*.js']) in your code, which means that Browserify will take all your .js files as entries into the bundle.
So I've put two entries in my code above, which manually replicates the pattern you use with the plugin. However, while Browserify does not produce an error with this setup, I suspect you don't actually want to have multiple entries. Typically, we pass one entry point to Browserify and let it trace the require calls to figure what it needs to pull.

How to copy multiple files and keep the folder structure with Gulp

I am trying to copy files from one folder to another folder using Gulp:
gulp.task('move-css',function(){
return gulp.src([
'./source/css/one.css',
'./source/other/css/two.css'
]).pipe(gulp.dest('./public/assets/css/'));
});
The above code is copying one.css & two.css to the public/assets/css folder.
And if I use gulp.src('./source/css/*.css') it will copy all CSS files to the public/assets/css folder which is not what I want.
How do I select multiple files and keep the folder structure?

To achieve this please specify base.
¶ base - Specify the folder relative to the cwd. Default is where the glob begins. This is used to determine the file names when saving in .dest()
In your case it would be:
gulp.task('move-css',function(){
return gulp.src([
'./source/css/one.css',
'./source/other/css/two.css'
], {base: './source/'})
.pipe(gulp.dest('./public/assets/'));
});
Folder structure:
.
├── gulpfile.js
├── source
│ ├── css
│ └── other
│ └── css
└── public
└── assets

I use gulp-flatten and use this configuration:
var gulp = require('gulp'),
gulpFlatten = require('gulp-flatten');
var routeSources = {
dist: './public/',
app: './app/',
html_views: {
path: 'app/views/**/*.*',
dist: 'public/views/'
}
};
gulp.task('copy-html-views', task_Copy_html_views);
function task_Copy_html_views() {
return gulp.src([routeSources.html_views.path])
.pipe(gulpFlatten({ includeParents: 1 }))
.pipe(gulp.dest(routeSources.html_views.dist));
}
And there you can see the documentation about gulp-flatten: Link

gulp.task('move-css',function(){
return gulp
.src([ 'source/**'], { base: './' })
.pipe(gulp.dest('./public/assets/css/'));
});
Your own code didn't include the entire dir tree of source 'source/**' and the base {base:'./'} when calling to gulp.src which caused the function to fail.
The other parts where fine.
gulp.task('move-css',function(){
return gulp.src([
'./source/css/one.css',
'./source/other/css/two.css'
]).pipe(gulp.dest('./public/assets/css/'));
});

Gulp watch, incremental build

I'm struggling to make gulp-watch behave as I desire. This small project is tooling to build HTML5 emails templates from Jade+SASS, in a repeatable way. The directory structure is as such:
.
├── Gulpfile.coffee
├── Gulpfile.js
├── build
│   ├── hello-world.html
│   └── styles
│   └── ink.css
├── node_modules
│   ├── ...snip...
├── package.json
└── source
├── hello-world.jade
├── layouts
│   └── default.jade
└── styles
└── ink.scss
My wish list is thus:
Build all templates when styles or templates change. This is what I can't do
Don't have a seaerate "cold" start, always use the gulp incremental build. (This seems to work)
Live reload would reload the browser, that'd be cool. (This too)
The Gulpfile, in CoffeeScript notation for brevity is included below, it's predominantly based on the documentation Incremental rebuilding, including operating on full file sets.
gulp = require 'gulp'
inlineCss = require 'gulp-inline-css'
jade = require 'gulp-jade'
marked = require 'gulp-marked'
plumber = require 'gulp-plumber'
rename = require 'gulp-rename'
sass = require 'gulp-sass'
cached = require 'gulp-cached'
util = require 'gulp-util'
watch = require 'gulp-watch'
webserver = require 'gulp-webserver'
styleGlob = "source/styles/*.scss"
templateAndLayouysGlob = "source/**/*.jade"
templateGlob = "source/*.jade"
styleChangeHandler = (event) ->
if event.type is "deleted"
delete cached.caches.scripts[event.path]
templateChangeHandler = (event) ->
if event.type is "deleted"
delete cached.caches.templates[event.path]
gulp.task "styleWatcher", ->
gulp.src(styleGlob)
.pipe(cached('styles'))
.pipe(watch(styleGlob))
.pipe(sass())
.pipe(gulp.dest("build/styles"))
.on('error', util.log)
gulp.task "templateWatcher", ->
gulp.src(templateGlob)
.pipe(cached('templates'))
.pipe(watch(templateGlob))
.pipe(jade(pretty: true))
.pipe(inlineCss())
.pipe(gulp.dest("build/"))
.on('error', util.log)
gulp.task 'webserver', ->
buildPath = 'build/'
gulp.src(buildPath)
.pipe(webserver({
livereload: true,
directoryListing: {
enable: true,
path: buildPath
},
open: true
}))
gulp.task "watch", ->
styleWatcher = gulp.watch(styleGlob, ["styleWatcher"])
styleWatcher.on 'change', styleChangeHandler
templateWatcher = gulp.watch(templateGlob, ["templateWatcher"])
templateWatcher.on 'change', templateChangeHandler
# I would expect this to fire when something in build/styles/*.css
# is updated by the style watcher?
templateStyleWatcher = gulp.watch('build/styles/*.css', ["templateWatcher"])
templateStyleWatcher.on 'change', templateChangeHandler
gulp.task "default", ["styleWatcher", "templateWatcher", "watch", "webserver"]
If it were possible, and I'd written this watcher in GNU Make or similar, I would have had the option to express that build/, and rely on the tooling to rebuild those files if the ones upon which they depend are out of date.
I've seen that there are a number of gulp-<something about inlining> plugins, but none of them make clear whether they support this conditional recompilation by watching paths that were imported for changes (I doubt it).
Given my background in systems programming, I may well be approaching Javascript build tooling in a completely incorrect way.