I have a regex which is repeatedly used in a number of classes. It's a violation of DRY and a potential pain if it needs to be changed in the future. Therefore I decided to move it to a common js and export it. Below is the code:
const CommonValues = {
TEXT_FILTER_REGEX: /^[,.?!:"—]$/
};
export CommonValues;
After importing CommonValues, I use it like this:
let result = CommonValues.TEXT_FILTER_REGEX.test('foo,bar'));
But no matter what I try, I keep getting this error in the console:
Uncaught Error: Module parse failed: 'const' can not be used as shorthand property (5:2)
You may need an appropriate loader to handle this file type.
I also tried exporting an integer and string the same way, they both worked without any trouble. This makes me wonder if regex is somehow treated differently when it comes to exporting?
This appears to have fixed itself miraculously. I'm totally baffled. I guess would be a temporary babel glitch.
Thanks for any advise.
I go it working by doing the below.
I'm not sure what your RegExp '/^[,.?!:"—]$/' does, but I tried with a digit RegEx =^[0-9]$ and got the expected result;
The error I got is about string type not having a test() defined on its prototype in TypeScript. Only RegExp has.
export const Constants = {
TEXT_FILTER_REGEX: new RegExp('^[,.?!:"—]$')
}
A working plunker is here
Test can be done the exact same way. You need to trim the /s and make it a RegExp object using a
new RegExp('UrRegexHere')
Related
I'm trying to read a JSON array. Every time i try to read the array/value by passing JSON object key like this-
json[key]
It shows a Eslint error-
[eslint] Generic Object Injection Sink (security/detect-object-injection)
I understand its a security warning because the key may not exists. But how do i resolve this warning? Is there any easier way to read the Json object. My plan is to pass the "key" to the function and read the json based on the key.
You are searching for an ES lint error fix:
Here is the syntax for it
json [`${key}`]
Example:
const obj = {
eventName: 'Music event',
landingPic: 'landing.jpg',
eventPic0: 'pic0.jpg',
eventPic1: 'pic1.jpg',
eventPic2: 'pic2.jpg',
eventPic3: 'pic3.jpg',
artist: 'Elie'
};
// array of keys which need to be read
const arrayOfKey = ['landingPic', 'eventPic0', 'eventPic1', 'eventPic2', 'eventPic3'];
// let's read the value by a key in array
arrayOfKey.forEach( key => {
const value = obj[`${key}`];
console.log(value);
});
There is a good answer here. In general this rule is for paranoiac and the article to which everyone appeal is a mislead. So the best answer, I would say is to turn this rule off, if you can for sure.
And another answer in the comments refers to eslint contributor answer that this rule is pretty false positive prone and more for human to audit a codebase(warning level) rather then give an error in a CI. So I would say you can totally ignore this rule or turn it off.
If you cannot turn it off or ignore, you can disable the eslint for line with comment that it's a false positive or use some interpolation as mentioned in other answers.
And finally, in order to destroy any doubts, the answer from creator of the rule:
"I'm the original author of this rule - for a bit of context, it was originally written as an assistive tool for manual code reviews, to be
used with the eslint plugin for VS Code. I would recommend disabling
it for other use cases, as it's just going to be far too noisy."
Unsure why, but typecasting the access parameter silences the error. Guessing this has something to do with sanitation being able to prevent pollution.
const myThing = myObj[String(key)]
const myThing = myObj[key as string]
What its trying to say is that using this notation:
You are able to modify even prototype properties of the object which is considered dangerous
By being able to modify everything, you are also able to modify the constructor (method/function) so it may be injected and then exploited.
The subject is described analytically here, providing a simple example:
https://web.archive.org/web/20150430062816/https://blog.liftsecurity.io/2015/01/15/the-dangers-of-square-bracket-notation
I use VS Code for JavaScript.
Definitions within a file work sometimes, but not others. Does anyone know why they fail?
In this example, VS Code finds the definition for edit easily. There is no occurrence of the word 'something' anywhere else in this file. Completely unique. So, why can't VS Code find its definition?
If I knew why, maybe I could change my code to work around it.
VS Code also can't find any references to these 'lost' properties. Which is very frustrating for tracking down where a function is called etc.
You should use this.
const edit = {
something: 5,
test() {
this.something;
},
};
You must not use an arrow function for test field, or this would point elsewhere but not the edit object.
EDIT: In TypeScript 4.3.5, the latest version of TS at the time of writing, TS is able to detect self-references in object literals, and both edit.something and this.something would work. For the case of working with JavaScript, upgrading VS Code should do the trick.
A TS playground link for reference.
There is a length limit. IntelliSense will define type :any if an object description is too long.
There is no way around this at all. The :any type will overwrite imported type definitions (e.g., a .d.ts file).
Two solutions:
Don't write long object declarations in your code.
Don't use VS Code or IntelliSense.
As for specifics:
The behavior is unpredictable.
If a type definition does not generate, reducing the object description length will not cause it to generate
Reducing an object description length to below the limit and re-launching VS Code will cause it to re-generate.
The length limit is unpredictable.
A function definition is 'longer' than a string, even if they have the same character count.
A nested ('deep') object declaration is longer than a shallow ('flat') object declaration, even if they have the same character count.
In short: IntelliSense breaks irreparably if you try to write long object declarations in a JS file.
I'm trying to read a JSON array. Every time i try to read the array/value by passing JSON object key like this-
json[key]
It shows a Eslint error-
[eslint] Generic Object Injection Sink (security/detect-object-injection)
I understand its a security warning because the key may not exists. But how do i resolve this warning? Is there any easier way to read the Json object. My plan is to pass the "key" to the function and read the json based on the key.
You are searching for an ES lint error fix:
Here is the syntax for it
json [`${key}`]
Example:
const obj = {
eventName: 'Music event',
landingPic: 'landing.jpg',
eventPic0: 'pic0.jpg',
eventPic1: 'pic1.jpg',
eventPic2: 'pic2.jpg',
eventPic3: 'pic3.jpg',
artist: 'Elie'
};
// array of keys which need to be read
const arrayOfKey = ['landingPic', 'eventPic0', 'eventPic1', 'eventPic2', 'eventPic3'];
// let's read the value by a key in array
arrayOfKey.forEach( key => {
const value = obj[`${key}`];
console.log(value);
});
There is a good answer here. In general this rule is for paranoiac and the article to which everyone appeal is a mislead. So the best answer, I would say is to turn this rule off, if you can for sure.
And another answer in the comments refers to eslint contributor answer that this rule is pretty false positive prone and more for human to audit a codebase(warning level) rather then give an error in a CI. So I would say you can totally ignore this rule or turn it off.
If you cannot turn it off or ignore, you can disable the eslint for line with comment that it's a false positive or use some interpolation as mentioned in other answers.
And finally, in order to destroy any doubts, the answer from creator of the rule:
"I'm the original author of this rule - for a bit of context, it was originally written as an assistive tool for manual code reviews, to be
used with the eslint plugin for VS Code. I would recommend disabling
it for other use cases, as it's just going to be far too noisy."
Unsure why, but typecasting the access parameter silences the error. Guessing this has something to do with sanitation being able to prevent pollution.
const myThing = myObj[String(key)]
const myThing = myObj[key as string]
What its trying to say is that using this notation:
You are able to modify even prototype properties of the object which is considered dangerous
By being able to modify everything, you are also able to modify the constructor (method/function) so it may be injected and then exploited.
The subject is described analytically here, providing a simple example:
https://web.archive.org/web/20150430062816/https://blog.liftsecurity.io/2015/01/15/the-dangers-of-square-bracket-notation
I am using TypeScript to generate some DOM element from a templated string. Now I know that in plain old javascript + JQuery you can do: var domObj = $(myString) or to make it more evident: var comObj = $('<div></div>'); and it works just like that.
I've been trying to do the same with TS and I always get some error telling me it can't say which overload to use.
Is there any other way to do what I'm trying to do?
Can it be done in TS?
Edit:
The issue I'm facing is not how to use JQuery from TypeScript is about a specific feature I want to load a string variable to a JQuery object, I know it can be done in plain old js but I get overloading errors when doing so.
Unlike this question which asks how to use JQuery from ts, which I have mostly figured out except for that little details I have just mentioned
Based on my comment above, you need to use a type assertion in order to avoid that error.
The most versatile option would be to use the any type since that will prevent typing errors from being thrown:
var comObj = ($('<div></div>') as any);
// or
var comObj = (<any>$('<div></div>'));
// or
var comObj: any = $('<div></div>');
Without seeing the full code, it's hard to know what exactly was happening in your case.
However, without context, it seems like the problem is that the compiler thinks that you are passing a string that represents a CSS selector, but in reality you were passing in stringified HTML, which results in the error that you are seeing.
As a side note, here is a relevant snippet in the TypeScript documentation under advanced intersection types. As you can see, the variable result is essentially coerced using the <any> type assertion:
let result = <T & U>{};
for (let id in first) {
(<any>result)[id] = (<any>first)[id];
}
I'm building a small TypeScript framework, for which I also want to ensure JavaScript compatibility. I have a class interface like this:
class Foo {
constructor(name : string, id : number);
}
Since this function might be called also from plain JavaScript, I also have some sanity check to ensure that the parameters actually have the correct types.
So far, so good. For this function I also have unit-tests written in TypeScript. What I want now is to have a unit-test that checks whether this function throws an exception when supplied with the wrong parameter types. For example:
new Foo(3) // throws an exception
// Undefined overload in TS
// But should be testable in TS for JS-compatibility
The problem now is, that when compiling such a unit-test it will throw an error, correctly stating that the function I'm trying to call doesn't exist. Meaning I can't compile my TypeScript unit-test.
The best workaround I have so far is to define these types of unit-tests as JavaScript tests and not TypeScript tests. But I'd rather group these tests together with all other tests for the class Foo, instead of splitting them, by Type- and JavaScript.
So, I'm looking for a way to tell the compiler that within the scope of my unit-test it's ok to call this undefined function, so I can test it. Or maybe define the signature for the scope of the test. Does anybody know if that's possible?
Thanks!
Pedro
It looks a bit nasty, but you can tell the compiler to treat Foo as any:
var a = new (<any>Foo)(3);
The <any> type assertion is the important bit.
You can override what Typescript is thinking about variable type using cast syntax:
var a = new Foo(<string> 42, <number> "not a number")
in this case you will get compile time error if you change the constructor signature even without running the test.