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.
Related
I don't know why am I getting the following error which say:
Error: Debug Failure. False expression: Non-string value passed to `ts.resolveTypeReferenceDirective`, likely by a wrapping package working with an outdated `resolveTypeReferenceDirectives` signature. This is probably not a problem in TS itself.
When i try to import the package inquirer in my nodejs application.
console.log("Hello world!");
import inquirer from "inquirer";
....
To run the application I'm using ts-node and I'm running it as follows:
ts-node index.ts
This is my package.json file:
{
....
"dependencies": {
"chalk": "^4.1.2",
"cors": "^2.8.5",
"cross-fetch": "2.6.1",
"dotenv": "^16.0.1",
"inquirer": "^8.2.4",
"ts-node": "^10.8.1",
"typescript": "^4.7.3"
},
"devDependencies": {
"#types/chalk": "^2.2.0",
"#types/cors": "^2.8.12",
"#types/inquirer": "^8.2.1",
"#types/node": "^17.0.42",
"nodemon": "^2.0.16",
"ts-node-dev": "^2.0.0"
}
....
}
I've tried to change the versions of inquirer and typescript but still it did not work.
What can be possibly the problem.
I have met with the same error but in my case I had no ts-node dependency installed, I fixed the error by adding that dependency.
You can also try to run your application with npx, in your case that will be npx ts-node index.ts.
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
I know there is topic on why this error occurs on here. My question is how to fix it in the NextJS environment and babel to produce chunks that don't include the spread operator in an object. Here is the background.
I need to support Edge18 where the spread operator is not supported in object destructing. It produces the error:
SCRIPT1028: SCRIPT1028: Expected identifier, string or number
The error is caused by this line:
filter(e=>"0"!==t[e]).reduce((e,r)=>({...e,[`-${r}`]:(0,f.default
And in particular the ...e
This code is in a NextJS chunk loaded via
<script src="/_next/static/chunks/269073627ff2c2dabb405b46af9d15fd8bf75a34.ed77311839e33222ab61.js" async=""></script>
How do I update the babel config to stop using the spread operator (ES2018) in an object? I am using typescript but the tsConfig target is ES5. I checked the browserslist per the Babel documentation for #babel/preset-env which links to browserslist and recommends using npx browserslist to see the target browsers for a project and Edge 18 is in there.
I do have a custom babel config per the docs here which follows the docs:
{
"presets": ["next/babel"],
"plugins": []
}
which has an added plugin that configures Styled Components for SSR. That's the only change. I appreciate any pointers in how to get NextJS to produce Chunks that don't contain the spread operator in an object or targets less than ES2018.
Edit: Here is package.json
"dependencies": {
"#apollo/client": "3.0.0-beta.50",
"#apollo/link-context": "^2.0.0-beta.3",
"#apollo/react-ssr": "^4.0.0-beta.1",
"#next/bundle-analyzer": "^9.4.4",
"#sentry/browser": "^5.15.5",
"#sentry/node": "^5.15.5",
"#zeit/next-source-maps": "0.0.3",
"downloadjs": "^1.4.7",
"framer-motion": "^1.11.0",
"geolib": "^3.3.1",
"geomagnetism": "^0.1.0",
"graphql": "^14.6.0",
"html-to-image": "^0.1.1",
"import": "0.0.6",
"leaflet": "^1.6.0",
"local-storage": "^2.0.0",
"lodash": "^4.17.15",
"mgrs": "^1.0.0",
"next": "^9.4.4",
"postcss-flexbugs-fixes": "^4.2.1",
"react": "0.0.0-experimental-33c3af284",
"react-dom": "0.0.0-experimental-33c3af284",
"react-icons": "^3.10.0",
"react-leaflet": "^2.7.0",
"react-spinners": "^0.8.3",
"react-transition-group": "^4.4.1",
"styled-components": "^5.1.1",
"uuid": "^7.0.3"
},
"devDependencies": {
"#graphql-codegen/add": "^1.15.0",
"#graphql-codegen/cli": "^1.15.0",
"#graphql-codegen/typescript": "^1.15.0",
"#graphql-codegen/typescript-operations": "^1.15.0",
"#graphql-codegen/typescript-react-apollo": "^1.15.0",
"#graphql-codegen/typescript-resolvers": "^1.15.0",
"#sentry/webpack-plugin": "^1.11.1",
"#types/downloadjs": "^1.4.2",
"#types/little-loader": "^0.2.0",
"#types/local-storage": "^1.4.0",
"#types/lodash": "^4.14.154",
"#types/node": "^14.0.6",
"#types/react": "^16.9.35",
"#types/react-dom": "^16.9.8",
"#types/react-leaflet": "^2.5.1",
"#types/react-transition-group": "~4.2.4",
"#types/styled-components": "^5.1.0",
"#types/styled-jsx": "^2.2.8",
"#types/uuid": "^7.0.3",
"#typescript-eslint/eslint-plugin": "^3.0.2",
"#typescript-eslint/parser": "^3.0.2",
"babel-eslint": "^10.1.0",
"eslint": "^7.1.0",
"eslint-config-airbnb": "^18.1.0",
"eslint-config-prettier": "^6.11.0",
"eslint-plugin-import": "^2.20.2",
"eslint-plugin-jsx-a11y": "^6.2.3",
"eslint-plugin-prettier": "^3.1.3",
"eslint-plugin-react": "^7.20.0",
"eslint-plugin-react-hooks": "^4.0.4",
"mapkit-typescript": "^5.18.2",
"postcss-preset-env": "^6.7.0",
"prettier": "^2.0.5",
"tailwindcss": "^1.4.6",
"typescript": "^3.9.3"
}
Edit 2: Here is the package analyzer of the package the chunk that is causing the issue (chunk ID is different because it's from development - same code found in here though)
Edit 3: I think the issue was tailwindcss. If I do the accepted solutions answer for tailwindcss an es-check es-check es6 'out/_next/static/chunks/*.js' returns the node_modules chunk as es6 compliant. If I then remove the transpire from the config, it marks the chunk as non es6 compliant at the same code that was erring in original post.
One of your dependencies is not using ES5-compliant code for older browsers and will need to be transpiled.
You need to narrow which dependency is producing this code and transpile it using babel. This dependency can be the result of a sub-dependency to a main dependency, so you may have to traverse the entire dependency tree all the way down to find the culprit. A simple example would be: #nivo is a React charting package that has a sub-dependency called d3-scale which dropped support for IE11 and can't be polyfilled, therefore it needs to be transpiled by babel to work in IE11:
next.config.js
module.exports = {
webpack(config, { defaultLoaders, isServer }) {
/* adds a custom Webpack rule for babel to transpile d3-scale */
config.module.rules.push({
test: /\.js$/,
loader: defaultLoaders.babel,
include: /[\\/]node_modules[\\/](d3-scale)[\\/]/,
});
/* return new config to next */
return config;
}
};
Alternatively, you can use the next-transpile-modules package that does the same thing as the above.
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
I'm working with expo and snack and keep getting this error
Unable to resolve module 'module://expo-font.js' Evaluating module://expo-font.js Evaluating module://react-native-elements.js
...
I'm not importing any fonts and by tracing the path above, can see that it faults in the 'react-native-elements' module
Here are the dependencies in package.json
"react-native-elements": "0.19.1",
"react-navigation": "1.0.0-beta.27",
"react-native-animatable": "1.3.0",
"react-redux": "5.0.7",
"redux": "4.0.0",
"redux-logger": "3.0.6",
"redux-persist": "5.10.0",
"redux-persist/lib/storage": "5.10.0"
I also do not have access to the App.json file on snack until export
In the past changing the react-native-elements version to something lower hacked it but that doesn't seem to do the job anymore
I solved it by importing "expo-font"
In the Expo interface, I updated package.json I did this and it works.The key is to add "expo-font":"^1.0.0". Behind the scenes it resolves to expo-font#1.1.0.
"dependencies": {
"#babel/core": "^7.0.0",
"react-native-elements": "^1.0.0-beta7",
"expo-font": "^1.0.0",
"expo-asset": "~1.1.1",
"expo-file-system": "~1.1.0",
"expo-constants": "~1.1.0"
}