I'm not sure what "at Free" means in this context, doesn't seem to be any kind of service or relevance here.
Beyond this, for node/typescript projects, generally speaking, you should use a .dockerignore file to exclude the things that shouldn't be copied into the container. From there, you should use multi-stage containers for your build pipeline... copy the entire project/solution or set of projects into a start or source container, then setup build containers for each portion (client, server, etc) and a final runtime container exposed for deployment.
Please don't post for every single release if it's less than a few weeks from a prior post. If you are posting for a specific release, you should link to the release page and/or release notes specifically.
dotenv is *NOT* meant to be used this way...
Generally speaking, do *NOT* commit your environment configurations (other than local development) to source control, you do *NOT* want variance in your configuration files, this is a deployment issue.
What you should do, is add `.env` to your .gitignore file so it doesn't get committed. You may want to add a `.env.dev.env` to source control with typical local settings. The dev env file should have a comment that you should copy it to a plain `.env` file for local development. You should also consider having fallback options in your configuration module, that represents the dev or production defaults as much as reasonable. ONLY load `.env` not ENVIRONMENT.env
Advice, load the .env file before loading any other modules, do it all synchronously, or an async load of your modules after environment and configuration are loaded. I would advise searching upward at least 2-3 directories for the .env then change your working directory to where the .env file is... for a static (non-container) deployment, this allows you to setup your .env in a parent directory from your application, and relative paths should work properly.
For containerized (docker) deployments, you should set the environment as part of your start/deployment model. Kubernetes, Dokku and other orchestration environments have options for this, you shouldn't deploy a .env file inside a container, and generally it should be mostly for development and/or static deployments.
Aside: you may, if using CI/CD for static deployments, want to use a `.env.template.env` file for transformation as part of your deployment model.
It's still prototype based inheritance with all the negatives... the syntax is sugar and sometimes nice, but should generally favor other patterns for performance.
I'm so meh on ORMs, especially in scripted languages, I understand this is TypeScript, but all the same.
If I'm going to take the time to really lay out all of the boilerplate needed for an ORM, I think I'd just assume go the extra step for GraphQL. There's even a similar typescript library for this[1].
[1] https://typegraphql.ml/docs/introduction.html
Nice... usually when I see more than 3 upvotes on an article, it's either pretty good/useful or spam. Glad it's the former.
Not sure I'd use storeon over redux in anything resembling a complex app though... there's value in the module system. Though, you could probably just copy and tweak as needed for the size of the main store, and use the rest with it.
Similarly, although I find other react-alikes interesting, the feature parity isn't there and real world performance isn't that impacted vs. having the extra dev support in react.
TailwindCSS does look interesting, it seems to be a bit more specialized than say Bootstrap + SASS, that said, I've been leaning into more prescriptive components (material-ui), and while I do find the need to customize, I like what JSS provides in that space.
If this were 6+ years ago, before React, I'd probably favor tailwind... now I favor components.
Completely agreed... I have the following (roughly) at the top of my scripts in current applications (IE is the main browser that doesn't support the features in question).
async functions and fetch...
try {
eval('(function() { async _ => _; })();');
if (typeof fetch === 'undefined') {
throw new Error('no fetch');
}
} catch (e) {
window.location.replace('/legacy.html');
}
The XMLHttpRequest API was based on the Microsoft.XMLHTTP COM library that could be used in older IE browsers starting with IE5 in 1998. Netscape (later Mozilla) added XMLHttpRequest as a native option to Gecko in 2002 and it became the norm, standardized in 2006, until fetch API became available a decade later in 2015.
Most articles that I've seen referencing the past with fetch to XMLHttpRequest tend to get muddled a bit.
https://en.wikipedia.org/wiki/XMLHttpRequesthttps://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Completely agreed... I have the following (roughly) at the top of my scripts in current applications (IE is the main browser that doesn't support the features in question). async functions and fetch... try { eval('(function() { async _ => _; })();'); if (typeof fetch === 'undefined') { throw new Error('no fetch'); } } catch (e) { window.location.replace('/legacy.html'); }