Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

275
Visualizações
Template literal throws errors in some scenarios but not others

As part of a code review a colleague recommended using a type rather than an enum. Whilst making the changes we found an issue neither of us expected.

We'd expect scenario one and two to throw compiler and/or intellisense errors as one of the values does not exist on the type. However, after testing we found only scenario one throws errors whilst scenario two resolves without issue.

This is likely an understanding issue but from everything I've read (e.g. Template Literal Types we should be getting errors when a provided value doesn't exist.

Based on the above, is anyone able to explain why we only see errors on scenario one but not the scenario two?

Scenario One

Example Code

export type FileType = ".png" | ".tif" | ".tiff" | ".jpeg" | ".jpg";

const allowedFileTypes = [".exe"] as Array<FileType>;

Expectation: Compiler error as .exe doesn't exist

Outcome: Compiler error stating the value doesn't exist

Scenario Two

Example Code

export type FileType = ".png" | ".tif" | ".tiff" | ".jpeg" | ".jpg";

const allowedFileTypes = [".exe", ".jpeg"] as Array<FileType>;

Expectation: Compiler error as .exe doesn't exist

Outcome: No compiler errors

Scenario Three

Example Code

export type FileType = ".png" | ".tif" | ".tiff" | ".jpeg" | ".jpg";

const allowedFileTypes = [".png", ".jpeg"] as Array<FileType>;

Expectation: No compiler errors

Outcome: No compiler errors

about 4 years ago · Juan Pablo Isaza
1 Respostas
Responde à pergunta

0

as Type is a way of saying "This value is this type, even if it doesn't look like it".

You're overriding normal type detection.

It's useful for things like:

const response = await fetch('/some/url');
const data = await response.json();
return data as Foo;

where you know what the shape of the data you are getting back from the HTTP request is, but the compiler has no way of telling that unless you use as to tell it explicitly.


It is dangerous since you can specify a type that doesn't match the value you actually have (as you've discovered).

I have a project underway where I'm using superstruct in order to test the shape of my data inside a typeguard function instead of trusting to as.


You need to specify what is allowed to be assigned to the variable instead:

const allowedFileTypes: Array<FileType> = [".exe", ".jpeg"];
about 4 years ago · Juan Pablo Isaza Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda