I used the following example to test tail call recursion with Babel and the es2016 preset:
'use strict';
try {
function r(n) {
if (n%5000===0)
console.log(`reached a depth of ${n}`);
r(n+1);
}
r(0);
} catch (e) {
if (!(e instanceof RangeError))
throw e;
else
console.log('stack blown');
}
My package.json file is:
{
"name": "tail-call-optimization",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"build": "babel es6 --out-dir es5 --source-maps",
"watch": "babel es6 --out-dir es5 --source-maps --watch",
"start": "node es5/app.js"
},
"author": "",
"license": "ISC",
"devDependencies": {
"babel-cli": "^6.6.5",
"babel-core": "^6.7.4",
"babel-loader": "^6.2.4",
"babel-polyfill": "^6.7.4",
"babel-preset-es2016": "^6.0.10",
"babel-runtime": "^6.6.1"
},
"dependencies": {
"babel-polyfill": "^6.7.4",
"source-map-support": "^0.4.0"
}
}
... and the .babelrc is simply:
{
"presets": ["es2016"]
}
Running the above with:
npm run build && npm run start
... results in the following console output:
reached a depth of 0
reached a depth of 5000
reached a depth of 10000
reached a depth of 15000
stack blown
Indeed, looking at the transpiled file in the es5 directory, there's nothing to suggest that TCO has been implemented.
Am I missing something?
My node version is 4.3.2.
Looking at: https://babeljs.io/docs/learn-es2015/ one reads:
Temporarily Removed in Babel 6
Only explicit self referencing tail recursion was supported due to the complexity and performance impact of supporting tail calls globally. Removed due to other bugs and will be re-implemented.
So I guess it's not presently implemented.
None of the "official" Babel 6 plugins / presets currently implements TCO. babel-preset-es2016 is not an "official" preset. Unless TCO relies on parser support in Babylon (off the top of my head I wouldn't think so, but I'm not sure) then I suppose a userland plugin / preset could implement it, and perhaps does (but not that I know of). Here is the issue tracking eventual "official" re-implementation: T2614. If someone wants to PR that link into the Learn ES2015 docs #Marcus mentioned ping me here and I'll merge it.
Related
I'm creating a new Next.js application.
When i run yarn create-next-app and i start to write javascript code inside Visual Studio Code, the ESlint extension throw back an error every time i digit.
And, naturally, eslint doesn't work.
The error is:
ESLint: Invalid Options: - Unknown options: env, parserOptions, rules - 'parserOptions' has been removed. Please use the 'overrideConfig.parserOptions' option instead. - 'rules' has been removed. Please use the 'overrideConfig.rules' option instead.. Please see the 'ESLint' output channel for details.
This is the image for an immediate visual recognizing:
Eslint extension error on Visual Studio Code
This is my package.json file (the default package.json given by Next.js):
{
"name": "myApp",
"private": true,
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "next lint"
},
"dependencies": {
"next": "12.0.7",
"react": "17.0.2",
"react-dom": "17.0.2"
},
"devDependencies": {
"eslint": "8.4.1",
"eslint-config-next": "12.0.7"
}
}
Thank you for your help.
Solved on my own by wrapping the content of esling.options into overrideConfig in my settings.json vscode file, like this:
"eslint.options": {
"overrideConfig": {
"env": {
"browser": true,
"es6": true
},
"parserOptions": {
"ecmaVersion": 2019,
"sourceType": "module",
"ecmaFeatures": {
"jsx": true
}
},
"rules": {
"no-debugger": "off"
}
}
},
This may be obvious to most, but I wanted to add one caveat. The above config fix works, but make sure you do it at the user level as well as the workspace level. If the eslint.options json doesn't have the overrideConfig at the user level config it will continue to error. Sorry if this is obvious, but I just spent the last hour trying to understand why I was continuing to get the invalid options error despite adding the above solution until I realized I was making the change in the workspace only. Hopefully this can save someone a headache.
I was not able to find the exact cause of the problem, but I was able to fix the issue by completely reinstalling vscode. Use this guide to do a clean uninstall.
I am using nvm-windows and I've two different node.js versions installed.
I am also working with nw.js but after having some problem with async/await I checked the node.js installation in use running:
nvm ls
I get:
* 14.6.0 (Currently using 64-bit executable)
5.11.0
But when I console.log the node.js version inside the nw.js app I get:
console.log(process.version);
console.log(process.versions['nw']);
console.log(process.versions['chromium']);
v5.12.0
0.14.7
50.0.2661.102
So I am clearly missing something!
Is there a way I can specify to nw.js the node.js version to use?
my package.json dependencies:
"dependencies": {
"#fortawesome/fontawesome-free": "^5.15.0",
"bootstrap": "^4.5.2",
"jquery": "^3.5.1",
"popper.js": "^1.16.1"
},
"devDependencies": {
"nw": "^0.48.3-sdk",
"nwjs-builder-phoenix": "^1.15.0"
}
Also inside package.json:
"scripts": {
"dist": "build --tasks win-x86,win-x64,linux-x86,linux-x64,mac-x64 --mirror https://dl.nwjs.io/ .",
"start": "run --x86 --mirror https://dl.nwjs.io/ ."
},
as suggested here because I am using nwjs-builder-phoenix
To solve the problem use nw u [version] like:
nw u 0.48.3
Then add this snippet to the package.json:
"build": {
"nwVersion": "0.48.3"
},
It is needed by nwjs-builder-phoenix to chose the nw version to use.
And run npm start again
[ Also helpful ]
To install a new nw version run nw i [version]
I try to build a small app based upon Webex web SDK, internally requiring regenerator-transform.
Here is my package.json simple file:
{
"scripts": {
"serve": "yarn build",
"build": "parcel index.html --out-dir dist --public-url ./",
"deploy": "git subtree push --prefix dist origin gh-pages",
},
"license": "MIT",
"dependencies": {
"crypto-js": "^4.0.0",
"moment": "^2.24.0",
"urijs": "^1.19.2",
"webex": "^1.80.147"
},
"browserslist": [
"last 2 major versions and >1%"
],
"devDependencies": {
"#babel/core": "^7.8.7",
"babel-preset-es2015": "^6.24.1",
"babel-preset-es2016": "^6.24.1",
"babel-preset-stage-0": "^6.24.1"
}
}
Here is my .babelrc file too:
{
presets : [ 'es2015', 'es2016' ]
}
It works perfectly when I use browserslist preset latest Chrome, but with this current query, I have this error:
[...]pkijs/src/SignedCertificateTimestampList.js: unknown Statement of type "ForOfStatement"
Full stack trace:
🚨 /Users/guillaumepotier/Sites/webex-sdk/node_modules/pkijs/src/SignedCertificateTimestampList.js: /Users/guillaumepotier/Sites/webex-sdk/node_modules/pkijs/src/SignedCertificateTimestampList.js: unknown Statement of type "ForOfStatement"
at Emitter.Ep.explodeStatement (/Users/guillaumepotier/.config/yarn/global/node_modules/regenerator-transform/lib/emit.js:587:13)
at /Users/guillaumepotier/.config/yarn/global/node_modules/regenerator-transform/lib/emit.js:323:12
at Array.forEach (<anonymous>)
at Emitter.Ep.explodeStatement (/Users/guillaumepotier/.config/yarn/global/node_modules/regenerator-transform/lib/emit.js:322:22)
at Emitter.Ep.explode (/Users/guillaumepotier/.config/yarn/global/node_modules/regenerator-transform/lib/emit.js:280:40)
at PluginPass.<anonymous> (/Users/guillaumepotier/.config/yarn/global/node_modules/regenerator-transform/lib/visit.js:111:17)
at PluginPass.<anonymous> (/Users/guillaumepotier/.config/yarn/global/node_modules/regenerator-transform/lib/util.js:28:17)
at newFn (/Users/guillaumepotier/.config/yarn/global/node_modules/#babel/traverse/lib/visitors.js:179:21)
at NodePath._call (/Users/guillaumepotier/.config/yarn/global/node_modules/#babel/traverse/lib/path/context.js:55:20)
at NodePath.call (/Users/guillaumepotier/.config/yarn/global/node_modules/#babel/traverse/lib/path/context.js:42:17)
It seems the problem is raised by regenerator-transform and the "ForOfStatement" within a generator, I tried many babel different configs but in vain.
My parcel --version gives me 1.12.4
Do you have any clue for that, how do you ship code with Parcel for IE11?
Meteor version 1.7.0.5
Using meteortesting:mocha
I have a very simple meteor react app. I added a test file in imports/startup/simple-schema.tests.js
describe('Todos_item', function () {
console.log('Todo');
});
I was running npm run test-app so it should be logged in console but that file actually doesn't run. But when I added this snippet to my tests/main.js Todo is logged in console. So am I missing something.
My directory tree
package.json
{
"name": "meteor-bootstrap",
"private": true,
"scripts": {
"start": "meteor run",
"test": "meteor test --once --driver-package meteortesting:mocha",
"test-app": "TEST_WATCH=1 meteor test --full-app --driver-package meteortesting:mocha",
"visualize": "meteor --production --extra-packages bundle-visualizer"
},
"dependencies": {
"#babel/runtime": "7.0.0-beta.55",
"meteor-node-stubs": "^0.4.1",
"react": "^16.4.2",
"react-dom": "^16.4.2",
"react-router-dom": "^4.3.1",
"simpl-schema": "^1.5.3"
},
"meteor": {
"mainModule": {
"client": "client/main.js",
"server": "server/main.js"
},
"testModule": "tests/main.js"
},
"engines": {
"node": "8.11.4"
}
}
Any help will be greatly appreciated. Thanks in advance.
New Meteor apps since 1.7 have eager loading turned off by default (which is causing your problem)
The behaviour is controlled by the meteor section in your package.json.
To restore the eager loading behaviour for tests, delete the testModule key-value pair from your package.json. It should look like this:
"meteor": {
"mainModule": {
"client": "client/main.js",
"server": "server/main.js"
}
},
If you want to restore pre-1.7 behaviour for all files, just delete the whole meteor section from package.json
If you don't want to use eager loading, you will need to import all of your test files from the tests/main.js file
Also one thing to add when with #Fred answer importing test files have to use require not import though I am not sure is it due to my node version or not I am using my node version v6.11.1
I'm attempting to transpile Salesforce Commerce Cloud's .ds files to JavaScript so we can apply standard testing tools (Jest, Mocha, etc.). The SFCC docs indicate that .ds files are "Rhino JavaScript", with a non-standard extension for Flow-like type checking.
So far, stripping out the type annotations has been simple, using the transform-flow-strip-types plugin. But SFCC supports a deprecated "for each...in" statement from JavaScript 1.6 that Babel is choking on.
All code below is available on github.
Here's my source src/index.ds file:
function dump(a: Array) {
for each (var x in a) {
console.log(x);
}
}
module.exports = dump;
And my gulfile.js:
const gulp = require('gulp');
const babel = require('gulp-babel');
gulp.task('test', function () {
gulp.src('src/**/*.ds')
.pipe(babel())
.pipe(gulp.dest('dst'));
});
And this is my package.json:
{
"name": "dspoc",
"version": "1.0.0",
"description": "poc",
"main": "index.ds",
"author": "cjr",
"license": "ISC",
"devDependencies": {
"babel": "^6.23.0",
"babel-core": "^6.26.3",
"babel-plugin-transform-flow-strip-types": "^6.22.0",
"gulp": "^3.9.1",
"gulp-babel": "^7.0.1"
},
"babel": {
"plugins": [
"transform-flow-strip-types"
]
}
}
When I run gulp test, I get this:
%> gulp test
[11:23:06] Using gulpfile ~/dev/dspoc/gulpfile.js
[11:23:06] Starting 'test'...
[11:23:06] Finished 'test' after 9.15 ms
events.js:163
throw er; // Unhandled 'error' event
^
SyntaxError: /Users/craser/dev/dspoc/src/index.ds: Unexpected token, expected ( (2:5)
1 | function dump(a: Array) {
> 2 | for each (var x in a) {
| ^
3 | console.log(x);
4 | }
5 | }
at Parser.pp$5.raise (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:4454:13)
at Parser.pp.unexpected (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:1761:8)
at Parser.pp.expect (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:1749:33)
at Parser.pp$1.parseForStatement (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:2008:8)
at Parser.pp$1.parseStatement (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:1836:19)
at Parser.parseStatement (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:5910:22)
at Parser.pp$1.parseBlockBody (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:2268:21)
at Parser.pp$1.parseBlock (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:2247:8)
at Parser.pp$3.parseFunctionBody (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:4235:22)
at Parser.parseFunctionBody (/Users/craser/dev/dspoc/node_modules/babylon/lib/index.js:5897:20)
I've spent quite a bit of time digging for a plugin that will let Babel transpile this to something like the for...of statement, but I can't seem to find anything.
I'm now at the precipice of digging into the for-of transform was built and creating something similar to transform for each...in, but I really don't want to have to put that work in if I can avoid it.
I feel like I'm missing something obvious here. Anyone know how this can be done?
for each...in was never an official part of the spec and didn't exist by the time Babel came around, so it is not supported by Babel. I'm afraid you've have to update all usage of that syntax before Babel will be able to process it.