We currently have a problem with our build pipeline that prevents certain parts of our legacy codebase from being transpiled.
Subsequently parts of our codebase have to be written in ES5 in order to be backwards compatible with older browsers.
The problem we're having is enforcing the use of ES5 code within these legacy scripts. There are a lot of places in the code where ES6 features (let, const, destructuring, object shorthand) are already used.
Adding an eslint config with the ecmaVersion set to 5 is not ideal because of the way the parser throws an exception on reaching an es6 feature, subsequently meaning no additional linting of the file happens. So you need to resolve all es6 type exceptions before this becomes an option.
We are unable to undertake a grand refactor of the code like this at present. As some parts are still being actively worked on. It is, in a word, a sh*tshow.
My question is, short of building some custom eslint plugin that highlights es6 features, is there any other solution that I may have missed?
As per #VLAZ' suggestion
https://github.com/nkt/eslint-plugin-es5
using the following config in eslintrc:
{
"plugins": [
"es5"
]
}
Worked perfectly for what we needed it for.
Related
While currently supported by Chrome, rollup rejects my es7 code:
[!] Error: Unexpected token
static/app.js (8:14)
6:
7: class App extends Component {
8: static name = 'MyES7App';
Error: Unexpected token
at error (/usr/local/lib/node_modules/rollup/dist/rollup.js:9435:30)
at Module.error (/usr/local/lib/node_modules/rollup/dist/rollup.js:13407:9)
at tryParse (/usr/local/lib/node_modules/rollup/dist/rollup.js:13320:16)
at Module.setSource (/usr/local/lib/node_modules/rollup/dist/rollup.js:13630:33)
at Promise.resolve.catch.then.then.then (/usr/local/lib/node_modules/rollup/dist/rollup.js:16460:20)
Is there a way to make it work? All I want is to bundle/minimize up some files into one, without taking care of cross-browser support or even transpiling.
The thing is, to be able to minify source code, tool should know about it. It is nearly impossible to minify source code like "plain text", all you can do is remove newlines and extra spaces. Minimizers are using parsers, to generate abstract syntax tree from the source code, and then works with this AST.
Rollup uses Acorn as JS parser, and by default it doesn't support class members. Even though they are available in Chrome, they are not in EcmaScript standard yet, it is proposal on stage 3.
So you need either different parser (like Babylon, which goes with Babel), or somehow teach Acorn of new language features.
I guess easiest way is to setup Babel and use rollup-plugin-babel, to support new syntax and proposals.
UPD Here is related Rollup issue, but looks like suggested Acorn solution is not working anymore...
I am using Visual Studio Code for my front end development. I have enabled the sort-keys rule which requires the keys of all object to be in alphabetical order.
I came to find out that neither ESLint, nor Prettier supports autofixing it, due to potential bugs the auto-fix can introduce, thus both of them has rejected the proposal to even consider adding auto-fix as option.
Now I have a very large legacy code base where I just added ESLint, and I need this sort-keys rule in the project. Is there any way I can auto-fix them provided I know what am I doing, possibly through some VSCode plugin or a custom script?
I am sure that changing the order of the keys will not affect my code negatively. I need it for both JSON objects as well as JS object literals.
Not exactly an automated solution but it helps with sorting object keys manually during development.
Sort JS object keys VS Code plugin
Install the plugin
Select an object in the code, including outer { and }. Hint: expand selection keyboard shortcut ⌃⇧⌘→ is helpful for this.
Run "Sort JS object keys" command.
I need confirmation on the following theory. According to TS docs, there are two options that can be set in tsconfig.json.
--allowSyntheticDefaultImports: Allow default imports from modules with no default export. This does not affect code emit, just typechecking.
--esModuleInterop: Emit __importStar and __importDefault helpers for runtime babel ecosystem compatibility and enable --allowSyntheticDefaultImports for typesystem compatibility.
When I google around, I see both being set to true (at least in regard to the behavior I'm aiming at). However, as far I understand the docs, TS and transpilation to JS, it makes no sense to use them both.
The way I figure, I might use the latter only and entirely remove the former. However, being cautious and humble, I'm not entirely certain and worry that I'm doing something less bright without realizing it at the moment.
I fear that it's something inappropriate that's going to bite me in the donkey later on causing hours of lamenting and hair-pulling while desperately trouble-shooting. The basis for the skepticism is that both options are available, so I'm inferring that there are four cases where all the combinations (true/false etc.) are required but I can't imagine which they are.
Is it entirely safe to skip --allowSyntheticDefaultImports if --esModuleInterop: true in compilerOptions? ANd if so, why do we have that option?
Bonus question: when is it required with all the four combinations (true/false) for those two options?
If you mean can you leave allowSyntheticDefaultImports undefined and define only esModuleInterop, the answer should be YES moving forward, but there has been an issue with this. PR #26866 seems to be a fix, only merged September 17, so it there may be some risk in the short term.
As why both exist, I believe these were both a part of addressing compatibility issues with imports of Babel-transpiled modules, the original PR added the allowSyntheticDefaultImports option to certain compile-time messages, but in practice didn't address the runtime behavior of the imports. So --esModuleInterop was added later. See TypeScript-Handbook/#816 for discussion of how to update the docs...
Well, my understanding is that the allowSyntheticDefaultImports is for being able to load CommonJS libraries in a simpler way if you target es6+ (in dev time) while esModuleInterop is for simplifying these imports (in runtime) if you target for example AMD (like I do).
According to the docs you shouldn't need to specify allowSyntheticDefaultImports explicitly if you have esModuleInterop enabled, but the reason I had to enable also the allowSyntheticDefaultImports is that Resharper seems to look at that that flag when doing syntax checking in Visual Studio. Sure it built and worked ok anyway with only esModuleInterop, but I got a lot of red warnings from Resharper until I enabled also the other flag.
According to the relevant documentation here : https://webpack.js.org/guides/typescript/, both options have different significance. Based on the project code and dependent library syntax, either/both options may be required.
I have the following code that basically gets some JSON data, looks for the keys with "servergenre", and saves the results in an array.
This is a follow up of this question.
let result = [];
Object.keys(data).forEach( key => {
if(/servergenre/.test(key)){
result.push(data[key])
}
});
Even though the code is working correctly, in some editors it raises syntactic errors:
"key": unsolvable variable or type key
"=>": expression expected
"if( / server...": formal parameter name expected
")){": , expected
"});": statement expected
Here is an image to show you where the errors are:
As I said the code is working fine, I just need it to be fixed or another approach to get rid of the errors.
Furthermore, many compressors and minifiers do not support this bit of code. So I can’t minify it.
Thanks in advance.
ES2015, formerly known as ES6, is a more recent version of JavaScript, which introduces features such as the => syntax for functions you are using.
Not all features of ES2015 are fully supported in all browsers, so many people who use it pass it through a compiler (“transpiler”) first to convert it to ES5, which is supported by all browsers. Babel is one such transpiler. But if you are only targeting newer browsers, that would explain why the => syntax is working for you.
You just need to change your editor settings to understand that syntax. Exactly how you do that depends on what text editor you are using. It could be that your editor's built-in JavaScript mode doesn't know how to read ES2015 syntax, and you need to either upgrade your editor or install a third-party plugin that provides an updated error-checker. Or it could be that your editor supports both ES5 and ES2015, and it thinks you are trying to write your project only in ES5. In this case you just need to go to the settings and tell your editor that you mean for this project to use ES2015 (or ES2016, which is currently the most recent version).
Fat arrows are ES6 syntax. If that causes trouble, just write good old ES5 :
let result = [];
Object.keys(data).forEach( function(key) {
if(/servergenre/.test(key)){
result.push(data[key])
}
});
In ESLint 1, I can use the ecmaFeatures option to disable or enable certain language features. E.g.
ecmaFeatures:
defaultParams: false
Above config disables defaultParams.
This is very useful because in runtime like Node, not all features are available, and I don't want to use a transpiler.
But in ESLint 2, that was removed. You only got ecmaVersion, which doesn't alerting on usage of ES2015 features at all even if you give it a ecmaVersion of 5. I guess this make sense since the JavaScript interpreter will complain about the usage of unsupported syntax at interpretation time, but what about developing for browsers have different level of ES2015 support? Syntax that works for Chrome won't work for IE9.
Is there any way to lint the usage of language features, e.g. disable destructuring?
no-restricted-syntax rule disallows specific syntax. This "syntax" is meaning the types of AST nodes. The spec of AST is here: https://github.com/estree/estree
eslint-plugin-node's no-unsupported-features rule disallows unsupported ECMA features by specific Node's version. I don't know whether a similar rule for browsers exists or not.