Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

TS2550 Error: 'startsWith' Does Not Exist on Type 'String' #57159

Closed
manuelricci opened this issue Jan 24, 2024 · 7 comments
Closed

TS2550 Error: 'startsWith' Does Not Exist on Type 'String' #57159

manuelricci opened this issue Jan 24, 2024 · 7 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@manuelricci
Copy link

🔎 Search Terms

"ts2550", "startsWith", "changing lib"

🕗 Version & Regression Information

I encountered a TypeScript compiler error in my project when trying to use the startsWith method on a string. The console outputs the following error message:

error TS2550: Property 'startsWith' does not exist on type 'string'. Do you need to change your target library? Try changing the 'lib' compiler option to 'es2015' or later.

4   return n > 5 && s.startsWith("A");

Step to reproduce the issue

  1. Use the startsWith method on a string variable in the TypeScript file.
  2. Compile the TypeScript code.
  3. Observe the error in the console.

⏯ Playground Link

https://www.typescriptlang.org/play?noImplicitAny=false&strictNullChecks=false&strictFunctionTypes=false&strictPropertyInitialization=false&strictBindCallApply=false&noImplicitThis=false&noImplicitReturns=false&alwaysStrict=false&esModuleInterop=false&declaration=false&target=3&jsx=0&module=1&ts=5.2.2#code/DYUwLgBAtgngYgVwHYGMwEsD2SBcEAUAhnkglAEYgBOANBOXgM5hXpIDmAlBALwB89TJlCEkAbgBQE2IlQZsvArgikK1OoyYs2XXgIDeEiBCrgEVJCogCArBABk9iIwB0zQlTCMA6ujAALfAAiAEEgzkkAXykZZDQsJHwANjoAchDQAA9UiKA

💻 Code

let myFunction: (a: number, b: string) => boolean;

myFunction = (n: number, s: string) => {
  return n > 5 && s.startsWith("A");
}

myFunction(6, 'Alex');

🙁 Actual behavior

The startsWith method should be recognized as a valid method on a string type, as per ECMAScript 2015 (ES6) standards.

🙂 Expected behavior

The TypeScript compiler throws an error stating that the startsWith method does not exist on the type 'string'.

The error suggests changing the 'lib' compiler option to 'es2015' or later. This could indicate an issue with the current TypeScript configuration not recognizing ES6 methods.

Additional information about the issue

TypeScript version: 5.3.2, 5.3.3 and 5.4.0-dev.20240124
Node.js version: v21.1.0
Operating System: Windows 11

I noticed that this error appears consistently in my local environment, regardless of the TypeScript version I use. Interestingly, when I attempted to reproduce this error in the TypeScript Playground, the issue did not occur.

This discrepancy suggests that the problem might be related to a specific configuration or environment issue on my local setup rather than a general bug in TypeScript. Any insights or suggestions to resolve this inconsistency would be greatly appreciated.

Here is my current tsconfig.json configuration:

{
  "compilerOptions": {
    "target": "ES2016",
    "lib": ["ES2016", "DOM"],
    "module": "commonjs",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "strictNullChecks": true,
    "skipLibCheck": true
  }
}
  • With Current Configuration: The error is shown in the console as described previously.
  • With Commented-Out Configuration: When I comment out all the options in tsconfig.json, VSCode still shows the same error. This happens before compilation, specifically marking the startsWith method with the same error message.

This behavior suggests that the issue might not be solely related to the specific settings in tsconfig.json, since the error persists even when these settings are disabled. It appears to be more closely related to how VSCode or the TypeScript compiler in my setup is interpreting the code.
@MartinJohns
Copy link
Contributor

MartinJohns commented Jan 24, 2024 •
edited
Loading

This is working as intended.

The error is correct when you don't have a matching tsconfig file. That's why you don't encounter the error in the playground. Your playground link targets ES2016. When you change it to ES5 you get the same error.

  • With Current Configuration: The error is shown in the console as described previously.

The error shouldn't be shown on the console with the configuration you posted. You probably invoke the compiler wrongly by passing a list of files to compile. In that case any local tsconfig is not used, as documented, and instead it's using the default compiler values (which is ES3 I think).

@manuelricci
Copy link
Author

My working directory contains the following files:

  • tsconfig.json
  • package.json
  • package-lock.json
  • app.ts
  • app.js

I invoke the compiler using the command tsc app.ts, which results in the error appearing.

In this scenario, any local tsconfig.json is not used, as documented. Instead, the compiler defaults to its built-in configuration values.

To further investigate, I checked which tsconfig.json file VS Code was referencing and found that it pointed to my working directory tsconfig.json. Subsequently, I modified the command to tsc -p ./tsconfig.json, and this change allowed the code to compile correctly.

@MartinJohns
Copy link
Contributor

I invoke the compiler using the command tsc app.ts, which results in the error appearing.

And that's the issue. Like I mentioned, when you provide a list of files to compile, then your local tsconfig file will not be used. This is working as intended and documented. You can't mix project files and a list of files to compile.

@RyanCavanaugh RyanCavanaugh added the Question An issue which isn't directly actionable in code label Jan 25, 2024
@RyanCavanaugh RyanCavanaugh mentioned this issue Jan 25, 2024
Open
@manuelricci
Copy link
Author

Thank you, @MartinJohns

I feel a bit embarrassed, as it's clearly stated in the first line of the CLI documentation.

Personally, I find this behavior a bit confusing. What are the reasons for the compiler to revert to its default configuration instead of using the "closest" one?

I was under the impression that the local tsconfig.json would override the default configuration, similar to how Git functions with its local, global, and system configuration files.

@MartinJohns
Copy link
Contributor

It's super easy to miss. There are a lot of issues about this. I don't know about the reasoning, it's probably written in some issue. I'd guess the tsconfig is meant as a project file, but when you compile individual files you're clearly not working on a project anymore.

@fatcerberus
Copy link

I always figured it was so tsc could be used in shell scripts without accidentally picking up tsconfigs from the CWD.

@RyanCavanaugh
Copy link
Member

Yeah, the concern was that pre-tsconfig builds would get broken during a migration step. This sounds far-fetched but at the time tsconfig was introduced, msbuild-based tsc invocations were very common (relative to overall TS usage back then).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fatcerberus @MartinJohns @RyanCavanaugh @manuelricci