Develop Reference

Cannot import and use postcss-simple-vars as a function

I am updating a PostCSS plugin to use PostCSS 8, and I am struggling with this error:
TypeError: vars(...) is not a function
The plugin is referenced in the code like so:
var vars = require('postcss-simple-vars');
...
vars({ only: value })(content);
The plugin was able to make this call before I updated the packages for it, but I'm not sure which one is breaking it. I've tried looking at the source code for postcss-simple-vars but I'm not understanding how this call isn't working.
These are the dependencies BEFORE upgrading:
"dependencies": {
"postcss": "^5.0.0",
"postcss-simple-vars": "^2.0.0"
},
"devDependencies": {
"chai": "3.2.0",
"gulp": "3.9.0",
"gulp-eslint": "0.11.1",
"gulp-mocha": "2.1.3",
"postcss-custom-properties": "^5.0.1"
}
AFTER updating packages:
"dependencies": {
"postcss-simple-vars": "^6.0.3"
},
"peerDependencies": {
"postcss": "^8.0.0"
},
"devDependencies": {
"chai": "4.3.6",
"gulp": "4.0.2",
"gulp-eslint": "6.0.0",
"gulp-mocha": "8.0.0",
"postcss": "^8.0.0",
"postcss-custom-properties": "^12.1.8"
}
The issue seems to be that postcss-simple-vars isn't importing as a function anymore, but I don't know why.
UPDATE
I managed to get it to at least partially compile using this invocation:
const {root} = postcss([vars({ only: value })]).process(content)
My issue with this is that it kind of goes against the principles of PostCSS 8. They mention in their migration guide that you really shouldn't have to import the postcss package anymore to perform operations in a plugin. Though this is technically performing an operation using a separate plugin, it still feels like it could potentially cause performance issues. I don't think I'm smart enough to know how or why though.

Gatsby-plugin-image: Missing image prop after update to v4 (Netlify)

We are having an issue with displaying images on Netlify after upgrading Gatsby to V4.
We have been using Netlify for the past 3 years for this project and everything worked fine until we tried to move to V4 of Gatsby.
We are using Strapi with Gatsby and our source plugin is gatsby-source-graphql.
I am also using createRemoteFileNode API to download images and store them locally.
exports.createResolvers = async ({ actions, cache, createNodeId, createResolvers, store, reporter }) => {
const { createNode } = actions;
await createResolvers({
STRAPI_UploadFile: {
imageFile: {
type: 'File',
async resolve(source) {
let sourceUrl = `${source.url}`;
console.log('source Url:', sourceUrl);
return await createRemoteFileNode({
url: encodeURI(sourceUrl),
store,
cache,
createNode,
createNodeId,
reporter,
});
},
},
},
});
};
As you can see above in the gatsby-node.js I have tried to console.log the image urls and they appear in the netlify build process. Could it be that there is something not working as expected in createRemoteFileNode API?
Here is the list of the dependencies.
"dependencies": {
"#headlessui/react": "^1.5.0",
"#heroicons/react": "^1.0.6",
"#loadable/component": "^5.15.0",
"babel-plugin-styled-components": "^1.12.0",
"cross-env": "^7.0.3",
"gatsby": "^4.13.1",
"gatsby-plugin-google-tagmanager": "^4.0.0",
"gatsby-plugin-image": "^2.13.0",
"gatsby-plugin-manifest": "^4.13.0",
"gatsby-plugin-offline": "4.0.0",
"gatsby-plugin-postcss": "^4.0.0",
"gatsby-plugin-react-helmet": "^5.13.0",
"gatsby-plugin-sharp": "^4.13.0",
"gatsby-source-filesystem": "^4.13.0",
"gatsby-source-graphql": "^4.13.0",
"gatsby-transformer-sharp": "^4.13.0",
"iframe-resizer-react": "^1.1.0",
"lodash": "^4.17.21",
"moment-timezone": "^0.5.33",
"prop-types": "15.7.2",
"react": "17.0.1",
"react-carousel": "^4.3.0",
"react-dom": "17.0.1",
"react-helmet": "6.1.0",
"react-markdown": "^6.0.0",
"react-modal": "^3.13.1",
"react-spinners": "^0.11.0",
"styled-components": "^5.3.0",
"use-media": "^1.4.0"
},
The images are working when built locally.
I have also tested this same setup on Gatsby Cloud and everything seemed to be working fine, but due to the business decisions we are unable to migrate to Gatsby Cloud.
Did anyone experience anything similar to this, or do you have maybe a solution to what this would be?
Below is the screenshot of a small portion of our deploy log which is covered with warnings about images missing in gatsby-plugin-image.

It looks like you shouldn't use createRemoteFileNode according to the migration guide. I'd be interested to see how you fixed this. https://www.gatsbyjs.com/docs/reference/release-notes/migrating-from-v3-to-v4/#do-not-create-nodes-in-custom-resolvers
Here's the fix: https://www.gatsbyjs.com/docs/reference/release-notes/migrating-source-plugin-from-v3-to-v4/#2-data-mutations-need-to-happen-during-sourcenodes-or-oncreatenode. Currently implementing myself.

In case anyone needs an answer:
The gatsby-source-graphql doesn't create any nodes (smallest unit of data) in Gatsby's data store so you can't attach/create image nodes directly with it. We had to make this change to support SSR and DSG.
If you’ve used this with gatsby-source-graphql, please switch to Gatsby GraphQL Source Toolkit. Generally speaking you’ll want to create your own source plugin to fully support such use cases.
You'll need to create proper nodes through a source plugin, I think the easiest way would be using gatsby-source-strapi instead of writing your own one.
You might ask yourself: Well, why does it "work" in Gatsby Cloud or locally? It's kinda a race condition and it's not stable or guaranteed that it always succeeds. So you can't rely on this.
Credits: LekoArts #lennart

Uncaught TypeError: moment.defineLocale is not a function in use locale for change calture

I use moment.js in typescript with webpack for create my own java-script client-side component and every things is OK.
Version of used components:
"dependencies": {
"circular-dependency-plugin": "^5.2.2",
"ignore-loader": "^0.1.2",
"moment": "^2.29.1",
"moment-locales-webpack-plugin": "^1.2.0",
"ts-loader": "^9.2.3",
"typescript": "^4.3.5",
"webpack": "^5.45.1",
"webpack-cli": "^4.7.2",
"webpack-dev-server": "^4.0.0-beta.3"
}
For add Persian culture like this example, I must write some code like this:
import * as moment from "moment";
import "moment/locale/fa";
console.log(moment.locale()); // en
moment.locale("fa");
console.log(moment.locale()); // muste be fa
Now i receive this error :
I think extra process that webpack do over .js file and simulate require() method case this problem. I search an find some question like my one, but answers is not usable.what is problem and how can I config webpack for fix this problem.
UPDATE:
After spend many hours in code. I find out that problem can be fix with this: For example for Persian culture in related .js setting file replace ../moment path with moment:
This solution is not god so need help for best way that don't need change in moment source code. I think some things like edit path routing in tsc or webpack config can fix this problem. Any suggestion? Thanks

The version of moment js support for moment.locale() is added # 2.8.0.
As of v2.8.1, moment.locale('en') sets the localization but does not return a moment.

Gulp without Gulpfile.js

I have a gulp project I inherited.
I am supposed to be migrating gulp v3 to v4.
However, I cannot find a gulpfile.js in this project at all.
Yet, every tutorial requires one. I am assuming there is some setup where the last developer knew about which is probably outdated?
Here is my folder structure:
All tasks are grouped in the Tasks folder. I want to say these exported with the root files which actually run those tasks files are my "gulpfiles".
All gulp tasks are ran using: node platform/build.js or node platform/deploy.js
I can make changes to this and everything, I see how he called it and wrote tasks. But I don't know the paradigm he is using to do this so it's difficult to know where to start migrating this to gulp v4.
Gulp libraries we are using:
"gulp": "3.9.1",
"gulp-autoprefixer": "6.0.0",
"gulp-bundle-assets": "2.29.0",
"gulp-concat": "2.6.1",
"gulp-csso": "3.0.1",
"gulp-data": "1.3.1",
"gulp-ejs": "3.3.0",
"gulp-empty": "0.1.2",
"gulp-eslint": "5.0.0",
"gulp-htmlmin": "5.0.1",
"gulp-if": "2.0.2",
"gulp-imagemin": "5.0.3",
"gulp-rename": "1.4.0",
"gulp-replace": "1.0.0",
"gulp-rimraf": "0.2.2",
"gulp-sass": "3.2.1",
"gulp-sass-lint": "1.4.0",
"gulp-sourcemaps": "2.6.5",
"gulp-string-replace": "1.1.2",
"gulp-strip-comments": "2.5.2",
"gulp-webserver": "0.9.1",
How it runs gulptasks:
// STEP 1 - process.env.NODE_ENV to staging
(!process.env.NODE_ENV) && (process.env.NODE_ENV = 'staging');
// STEP 2 - Prevent from running on NON-CI
if (!process.env.CI) {
throw new Error('Build can only be performed in CI Environment');
}
// START PROCESS
const _ = require('lodash'),
gulp = require('gulp'),
Tasks = require('./tasks'),
runSequence = require('run-sequence').use(gulp),
// This of the tasks here is the order in which they will executed
taskMap = {
'clean:dist': Tasks.cleanDist,
'clean:tmp': Tasks.cleanTemp,
'copy:assets': Tasks.assetCopy,
'bundle': Tasks.bundleAssets,
'transpile': Tasks.transpile,
'prefixCss': Tasks.autoprefixCss,
'sitemap': Tasks.sitemap,
'robots': Tasks.robots,
'remove:htmlext': Tasks.removeHtmlExt
};
// Create all tasks
_.forEach(taskMap, (value, key) => {
gulp.task(key, value);
});
// #todo: Shift to using gulp.series when gulp is upgraded to v4
gulp.series(..._.keys(taskMap))();

A gulpfile is really just a chunk of Javascript code - it's named with a default name so when you run gulp it finds it by default.
You actually have gulpfiles - they're each of those individual .js files you're talking about.
I suspect they were split up this way because somebody thought there were too many tasks in each one and wanted to separate them by "topic" somehow.

I inherited a project that used Gulp with no gulpfile a while back. It turned out it was actually inside of a shared gulpfile which was hosted on npm (like https://github.com/jonathantneal/gulp-config-dev). Long shot, but perhaps it's listed as a dependency in package.json.

XMLHttpRequest not working as expected after package electron

I have a electron project that uses ffi-napi to integrate some cpp code and uses electron-forge / electron-compile to package the app.
Everything works fine when i run "electron-forge start".
My javascript uses XMLHttpRequest to load in some binary data from a custom file format (*.awd). XMLHttpRequest.responseType is "arraybuffer".
The problem is, that once i use "electron-forge package" and run the resulting app, the XMLHttpRequest in my javascript no longer works as expected. It does not throw a error, but the XMLHttpRequest.result is much smaller than it should be, so the parsing of the binary data fails.
This are the versions of electron-forge / electron-compile that i am using:
"dependencies": {
"electron-compile": "^6.4.4",
"electron-squirrel-startup": "^1.0.0",
"ffi-napi": "^2.4.4",
"ref": "^1.3.5"
},
"devDependencies": {
"babel-plugin-transform-async-to-generator": "^6.24.1",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "^6.24.1",
"electron-forge": "^5.2.4",
"electron-prebuilt-compile": "4.0.0",
"eslint": "^3.19.0",
"eslint-config-airbnb": "^15.1.0",
"eslint-plugin-import": "^2.15.0",
"eslint-plugin-jsx-a11y": "^5.1.1",
"eslint-plugin-react": "^7.12.4"
}
Any help on this would be very much appreciated!

I think i found the solution myself.
The problem is with the "electron-compile" module. After running "electron-forge package" it seem to interfere when loading my custom binary files and prevent them from being loaded correctly via XMLHttpRequest.
The solution seems to use the "addBypassChecker" that comes with the electron-compile package to ignore files to be recompiled by electron-compiled if they are not part of the App.
import { app } from 'electron';
import { addBypassChecker } from 'electron-compile';
addBypassChecker((filePath) => {
return filePath.indexOf(app.getAppPath()) === -1;
});
more infos here:
https://github.com/electron-userland/electron-compile/pull/199