@piluvitu

.env

• Para quem não sabe o seu sistema por padrão tem variáveis de ambiente, que servem para armazenar alguma informação e padronizar o acesso dela pela mesma.
  • É possível inserir váriáveis no próprio sistema sem precisar de nem uma abstração, mas ela não são inserções persistentes, por isso a fim de facilitar a definição dessas variáveis, existe o módulo do NPM .env, que foi criado a fim de facilitar isso.
• Para usa-lo tudo que é necessário fazer é criar um arquivo .env na raiz do projeto e inserir as variáveis com a seguinte sintaxe:
• O modelo é chave – valor, com a chave sendo por padrão MAIUSCULA

OPENIA_KEY = informação sensivel URL = localhost PORT = 3000

• Muito se é discutido em upar ou não o .env então devemos explicar o comportamento dele no sistema:
• .env.development – serve para um ambiente de desenvolvimento
• .env.example – serve como um arquivo de exemplo

• .env – é o arquivo padrão, que em teoria seria usado para inserir as variáveis de produção.

• Muitos dos provedores onde podemos subir nossas aplicações de maneira facilitada, disponibilizam uma parte para inserirmos as variáveis de ambiente que serão utilizadas na nossa aplicação e por ordem de importância essas variáveis inseridas antes do deploy, são as que vão realmente sobrepor as que ficam no .env.

  GIT
  

• Pensando nisso o GitHub fez um artigo que sugere usar uma ferramenta do próprio git ou uma ferramenta open-source

  • Falando em git, descobri que tem como renomear arquivos usando o próprio git usando o comando git mv:
    git mv

Absolute PATH

• Eu nunca tinha parado para pensar que, quando queremos acessar algum arquivo que está fora da pasta atual:
  1 – Navegamos para fora da pasta atual
  2 – Entramos na pasta do arquivo
  3 – Por fim referenciamos o mesmo.
• O nome disso é relative PATH e percebemos que priemeiro voltamos para depois seguir em frente, que em um projeto com muitos arquivos gera um PATH longo e nada didático
  • Já o absolute PATH é o caminho absoluto, que toma como padrão sempre sair da raiz do projeto e ir para o arquivo desejado, encurtando o PATH e deixando didático
• Fica a dúvida de como eles fazem para referenciar o diretório raiz do projeto ?
• Existem várias soluções no mercado, mas a microsoft desenvolveu os arquivos jsconfig.json e tsconfig.json que servem para indicar ao editor que ali é a raiz do projeto.

TypeScript

Por fim o typescript, meu primeiro contato sem auxilio de curso tem sido aqui na devhat, no projeto octopost, mal conheço e já considero pacas esse TS, estou fazendo minha introdução pelo curso da origamid.

• Estudei conceitos básicos de annotation, inferface e inferência.

// Annotation
const produt0: string = 'Livro'

let prec0: number = 856

• No TypeScript podemos tipar, e isso é interessante pois evitamos erros na hora de lidar com os dados

Interface

// Interface
const carr0: {
  marca: string
  portas: number
  motor: number
} = {
  marca: 'audi',
  portas: 2,
  motor: 3.0
}

carro.marca = 245
carro.portas = '2'
carro.motor = ['aspirado', 'alumínio']

Inferência

/* Mesmo sem declarar a tipagem, alguns tipos de variáveis o TS, 
já identifica a tipagem correta */

// Annotation
const produtos = 'Livro'

let preco = 856

preco = 'jajaja'

// Interface
const carro = {
  marca: 'audi',
  portas: 2,
  motor: 3.0
}

carro.marca = 245
carro.portas = '2'
carro.motor = ['aspirado', 'alumínio']

• Como pode-se ver no exemplo acima, podemos deixar de declarar a tipagem de alguns dados que o proprio TypeScript já reconhece.

function somar(a: number, b: number){
    return a + b;
}
soma(4, 10)
soma(4, "10")

• No exemplo acima é possivel ver um otimo motivo para tipar, pois saberemos o que é para chegar no parâmetro e o que será retornado

FunFact

• O vsCode tem intelisense de JS graças ao TS nativamente no editor, caso queira ter um pouco da experiência de usar TS no JS é só adicionar //@ts-check na primeira linha do seu arquivo JS e o editor vai passar a indicar alguns erros que o TS pegaria no seu código

@hxsggsz

Typescript

Essa semana eu estudei bastante Typescript pra tentar resolver um problema. Durante esse estudo eu descobri alguns Utilities Types criados pelo próprio time do Typescript pra facilitar a nossa vida difícil de bugs.

Como esses “Utilities Types” funcionam

Todos eles se beneficiam dos “Generics”, algo muito útil na hora de tipagem e que é presente em diversas linguagens estaticamente tipadas.

Partial

O que ele faz? Ele transforma tudo em um objeto opcional. Olha esse exemplo:

interface User {
    id: string
    name: string
    role: "admin" | "user"
}

Agora se a gente taca essa interface no Partial assim:

type OptionalUser = Partial<User>

É como se a gente fizesse isso

interface User {
    id?: string
    name?: string
    role?: "admin" | "user"
}

Required

Existe o oposto do Partial que é o Required, e como o nome já diz, ele transforma todos os tipos que ele receber para necessário fornecer, até os que originalmente são opicionais

type OptionalUser = Partial<User>

type RequiredUser = Required<OptionalUser>

E agora o tipo RequiredUser fica assim

interface User {
    id: string
    name: string
    role: "admin" | "user"
}

Omit

Agora imagina que a gente quer omitir o nome da interface User sem alterar a interface original, essa é a função do Omit.

type UserWithouName = Omit<User, "name">

Pick

E tem o contrario também, imagina que a gente quer pegar apenas a propriedade nome da interface mas sem alterar a interface original, o Pick serve pra isso.

type UserName = Pick<User, "name">

Se você quiser pegar ou excluir mais de uma propriedade, basta usar o pipeline

type UserName = Pick<User, "id" | "name">

// ou 

type UserName = Omit<User, "id" | "name">

É possível combinar todos esses Utilities Types também

type UserNameOptional = Partial<Pick<User, "name">>

ReturnType

Agora imagina que a gente tem esse tipagem de função aqui:

type HandleSomething = () => string

E você precisa ter a tipagem do retorno dessa função, pra isso existe o ReturnType

type ReturnOfHandleSomething = ReturnType<HandleSomething>

Awaited

Imagina que você tem uma tipagem que é uma promise

type AwaitSomething = Promise<string>

E você quer a tipagem que essa promise vai retornar, pra isso serve o Awaited

type Result = Awaited<AwaitSomething>

Agora um caso um pouco mais real, você tipou uma função que retorna uma promise e você quer separar um type diferente o retorno dessa função, simples:

type UserNameOptional = () => Promise<string>;



type Result = Awaited<ReturnType<UserNameOptional>>;

Um exemplo com uma função real

async function awaitSomething() {
  await new Promise(() => setTimeout(() => "demorei mas cheguei", 1000));
}

// string
type Result = Awaited<ReturnType<typeof awaitSomething>>; 

The post TIL – Today I Learn 12-11 18-11 parte 2 appeared first on ProdSens.live.

Hello javascript lovers too, for some time now the new version of node, more precisely version 20.6.0, has been supporting your environment variable file without the need for an external package to do this. Well, in this little article we’re going to talk a bit about what this means and how to take full advantage of this improvement, as well as some of the drawbacks or weak points of this functionality.

To begin with, environment variables are essential for our code, and their usefulness is well established. This allows us to avoid exposing sensitive data in our source code, and also to easily change certain configurations in our application without having to hardcode them.

In the development world, we’re used to using a file to store our data. Often we call it .env .env.local env.uat .env.prod, depending on your environment.

In javascript, the essential package for managing configuration files was dotenv, which was used, and still is today, to load env files and perform other configuration. Since node version 20.6.0, you can do it without this package.

What’s the advantage of using this

Firstly, this means we don’t have to depend on an external library, and therefore limit security failures in our code.

more simplicity, so we won’t need to install and configure the dotenv package in our project as we used to do.

So without further ado, let’s get to work!

So I’m not going to tell you again to install node version 20.6.0 – I assume you’ve already done that – but for a little tip I recommend using nvm (node version manager), which lets you have several versions of node installed on your computer, so you can easily switch versions independently of the projects you’re working on.

create a folder and initialize a project node with the command

npm init --yes

once this is done create two files index.js and .env at the root of your folder, place this content in the .env file

PORT=3000
APP_NAME=fake-app-name
LOG_LEVEL=debug

and this in the index.js file

console.log(process.env.PORT)
console.log(process.env.APP_NAME)
console.log(process.env.LOG_LEVEL)

Now to launch your little application, type the following command in your terminal and you’ll see the contents of your different environment variables displayed.

node --env-file=.env index.js

as you can see, we didn’t have to install anything or configure anything to have our variables available in the code, now it’s up to you to improve it and define the file by environment.

{
  "name": "test_env",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start:dev": "node --env-file=.env index.js",
    "start:uat": "node --env-file=.env.uat index.js",
    "start:prod": "node --env-file=.env.prod index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

From the release of this announcement there have been some questions about this feature, for example:

It doesn’t traverse parent directories, doesn’t have good overwrite/merge logic – things that dotenv supported.

It doesn’t support multiline variables, which are very important for keys, certificates and JSON configuration.

Above all, it should be noted that this functionality has been made public and that it’s up to the community to decide how to improve it and make it more suited to our needs.

The post Node(20.6.0) now supports built-in .env files appeared first on ProdSens.live.