Maybe someone faced such a problem? I tried to change versions of the compiler, after changing 1 time it accumulates without errors, it crashes again with the same error. Tried 0.64.0, 0.63.0, 0.62.0, 0.61.0, On the last one instead of "[ERROR] undefined" returned "[ERROR] Error: 1". What is the problem?
At the same time, everything passes through ""everdev sol compile"" norms. I don’t really want to switch from locklift, but got stuck due to a mistake.
Thanks!
npx locklift init --path amazing-everscale-project
cd amazing-everscale-project
npm install --save-dev everdev
npx everdev sol set --compiler 0.64.0 --linker 0.18.4
Update locklift.config.ts
const config: LockliftConfig = {
compiler: {
path: "~/.everdev/solidity/solc",
},
linker: {
lib: "~/.everdev/solidity/stdlib_sol.tvm",
path: "~/.everdev/solidity/tvm_linker",
},
...
build
npx locklift build
Related
my team is migrating to rush and I had a problem while setting it up: I'm getting a weird error when trying to add any 3rd party lib (let's say react) to package.json using rush add --package react (for example). The error log:
Found configuration in /home/ivan/dev/JS/eisbuk/rush.json
Rush Multi-Project Build Tool 5.66.2 - https://rushjs.io
Node.js version is 14.19.0 (LTS)
Found configuration in /home/ivan/dev/JS/eisbuk/rush.json
Starting "rush add"
Determining new version for dependency: react
No version selector was specified, so the version will be determined automatically.
Trying to acquire lock for pnpm-6.32.3
Acquired lock for pnpm-6.32.3
Found pnpm version 6.32.3 in /home/ivan/.rush/node-v14.19.0/pnpm-6.32.3
Symlinking "/home/ivan/dev/JS/eisbuk/common/temp/pnpm-local" --> "/home/ivan/.rush/node-v14.19.0/pnpm-6.32.3"
The "ensureConsistentVersions" policy is NOT active, so we will assign the latest version.
Querying NPM registry for latest version of "react"...
ERROR: The command failed with exit code 243
I tried to find a similar problem report related to rush and looked up the 243 error with npm, both to no avail. I'm using pnpm, however, the error persists with npm and yarn all the same (with yarn it's exit code 1, everything else is the same).
Here's my .npmrc (a default really):
registry=https://registry.npmjs.org/
always-auth=false
Interestingly enough, if I manually add a dependency to package.json and run rush update, the update goes well and the dep is added to node_modules and shrinkwrap (so it shouldn't be an npm registry problem).
Here's my rush.json:
{
"$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",
"rushVersion": "5.66.2",
"pnpmVersion": "6.32.3",
"pnpmOptions": {
"preventManualShrinkwrapChanges": true,
"useWorkspaces": true
},
"nodeSupportedVersionRange": ">=12.13.0 <13.0.0 || >=14.15.0 <15.0.0 || >=16.13.0 <17.0.0",
"gitPolicy": {},
"repository": {},
"eventHooks": {
"preRushInstall": [],
"postRushInstall": [],
"preRushBuild": [],
"postRushBuild": []
},
"variants": [],
"projects": [
/** ...other projects */
{
"packageName": "#eisbuk/functions",
"projectFolder": "packages/functions"
}
/** ...other projects */
]
}
The entire repo can be found at: https://github.com/eisbuk/EisBuk/tree/feature/rush
Solved!
In the end, I've managed to pinpoint it to the node version. I was using v14.19.0 and bumping to v16.14.2 solved it. I don't know if it's a known incompatibility, but here it is.
I have a project that's been running perfectly for a few months now, able to run npm run serve with no problem. I have to terminate and run the command again whenever I switch networks, but that has never been a problem and the server could always start again.
Until now - no matter what I do I can't get the server to start. I get this error:
npm run serve
> xbs#0.6.2 serve D:\workspace\[PROJECT]
> vue-cli-service serve
INFO Starting development server...
10% building 1/1 modules 0 active ERROR TypeError: Cannot read property 'upgrade' of undefined
TypeError: Cannot read property 'upgrade' of undefined
at Server.<anonymous> (D:\workspace\[PROJECT]\node_modules\webpack-dev-server\lib\Server.js:667:47)
at Array.forEach (<anonymous>)
at new Server (D:\workspace\[PROJECT]\node_modules\webpack-dev-server\lib\Server.js:666:22)
at serve (D:\workspace\[PROJECT]\node_modules\#vue\cli-service\lib\commands\serve.js:137:20)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:188:7)
at Function.Module.runMain (module.js:695:11)
at startup (bootstrap_node.js:191:16)
at bootstrap_node.js:612:3
The last time I got this message was when I forgot to set the .env files, but this is a previously working copy with all necessary files set, and no changes since the last working run.
I've even tried pulling a fresh copy of the repo, running npm i and setting all env files but it still fails.
npm run lint and npm run build can still work, only npm run serve.
Am I missing anything?
The problem was again with the .env files. My vue.config.js was trying to access a previously set environment variable that had since been removed.
Only strange thing was that there weren't any problems up til now?
I guess your devServer.proxy.target is empty!
You could set this configuration
For me it was that I forgot to create (or copy from another PC) the .env file after clone and try to run my project on another PC.
I also had this problem.
I used in the project process to get the backend address(for example):
devServer: {
proxy: {
'/api/back/*': {
target: process.env.VUE_APP_BACKEND_URL,
pathRewrite: {
'/api/back': '/api/back',
},
},
},
},
But there was no .evn file.
Just create .env file:
VUE_APP_BACKEND_URL= 0.0.0.0:2222 #example
Didn't notice the answer #Sergey.
I declared this environment variable in .env.dev, but the local build failed, and the same project ran without problems, so I created a new .env file and declared it in it
proxy: {
'/api': {
target: process.env.VUE_APP_PROXY,
changeOrigin: true,
pathRewrite: {
'^/api': ''
}
}
}
I did not change anything in app.scss, but when I run npm run watch I get the following errors:
error in ./resources/sass/app.scss
Module build failed (from ./node_modules/sass-loader/lib/loader.js):
Unsupported operation: Cannot extract a file path from a URI with a fragment component
# ./resources/sass/app.scss 2:14-254
Asset Size Chunks Chunk Names
/js/app.js 2.46 MiB /js/app [emitted] /js/app
ERROR in ./resources/sass/app.scss
Module build failed (from ./node_modules/css-loader/index.js):
ModuleBuildError: Module build failed (from ./node_modules/sass-loader/lib/loader.js):
undefined
^
Join(null, "variables"): part 0 was null, but part 1 was not.
#import 'variables';
^^^^^^^^^^^
stdin 2:9 root stylesheet
in C:\Users\TAQI VAHEED\Desktop\#Coding\resPro\resources\sass\app.scss (line 2, column 9)
at runLoaders (C:\Users\TAQI VAHEED\Desktop\#Coding\resPro\node_modules\webpack\lib\NormalModule.js:30
at C:\Users\TAQI VAHEED\Desktop\#Coding\resPro\node_modules\loader-runner\lib\LoaderRunner.js:364:11
at C:\Users\TAQI VAHEED\Desktop\#Coding\resPro\node_modules\loader-runner\lib\LoaderRunner.js:230:18
at context.callback (C:\Users\TAQI VAHEED\Desktop\#Coding\resPro\node_modules\loader-runner\lib\Loader
13)
Any help appreciated.
Finally found the issue. It is related to dart-sass being used instead of node-sass with laravel-mix v4.x.x.
Turns out something related to dart-sass or laravel-mix does not work well with paths containing a '#' symbol. In your case, your app is located at C:\Users\TAQI VAHEED\Desktop\#Coding\resPro and the #Coding folder is creating the error.
Either move your app somewhere else without a '#' symbol in the path OR enable node-sass again by following the steps from laravel-mix 4.0.0 release notes:
you can manually switch back to node-sass, like so:
npm install node-sass
mix.sass('resources/sass/app.sass', 'public/css', {
implementation: require('node-sass')
});
in your webpack.mix.js write the code
mix.js('resources/js/app.js', 'public/js')
.postCss('resources/css/app.css', 'public/css');
I'm having some issues on Windows env. with npm & a package.json, mainly with one of the devDependencies, concat-cli.
Here's a little sample of the package.json file:
...
scripts{
...
"js-vendor-concat": "concat-cli -f src/js/vendor/**/*.js -o dist/js/vendors.js",
...
}
....
"devDependencies": {
...
"concat-cli": "^4.0.0"
...
}
So what happens is that every time I run that script in Windows env, I get Error: Error: EISDIR: illegal operation on a directory, read at errorHandler (index.js:11:15). Thing is that on linux, this error doesn't come up.
Things tried so far:
used git-bash and cygwin but same outcome
changed the input path to: src/js/vendor/*.js, again same outcome
However if I specify the name of the file, it works, so I'm guessing its something related to that wildcard *.js selector?
Any tips or pointers are much appreciated, thanks!
I have using browserify for new project. It works really well so far.
I have one big issue though. How can I debug each js file separately. It bundles all the files together and points to bundle if error occurs.
I am using chrome and source maps but it doesn't really help in debugging.
Any ideas?
Update: More info:
I'm using this command in package.json
"start": "watchify scripts/main.js -o scripts/bundle.js --debug",
and getting errors as shown above which is not ideal.
I believe my source maps are on?
I'm not exactly sure how you are using the command line tool for browserify without any code, but you you should be able to utilize debug.
--debug -d Enable source maps that allow you to debug your files
separately.
browserify main.js -o bundle.js --debug
For more info on the CLI tool you can look here - https://github.com/substack/node-browserify#usage
Edit After a bit more digging on this - the issue specifically being hit here is a ParseError - which means that Browserify is never actually getting to the proper debug stage. Hadn't really thought it through, but this made perfect sense.
In order to test this - I create two simple files:
a.js
module.exports = function(a) {
return a;
}
main.js
var a = require('./a.js');
console.log(a("something"));
I then ran browserify using watchify with an npm script:
"start": "watchify main.js -o bundle.js --debug"
Using the script in a browser, and everything worked great - it logged to console as expected. I then edited a.js with a typo:
a.js
module.exports = function(a) {
return a---
}
The browser and watchify threw the error shown above: path/to/file/a.js:3 ParseError: Unexpected Token.
Browserify is not able to compile the file properly, so it's throwing an error. You should be seeing this in the console during the build.
To test that the --debug flag works as expected, I modified the code again:
a.js
module.exports = function(a) {
return a('something');
}
The expectation here would be a TypeError since the function now expects a to be a function.
The console in the browser now displays:
Uncaught TypeError: a is not a function __________ a.js:2
Fix your parse issues, and browserify --debug will once again start behaving as expected.